Es posible planear y costear proyectos agiles!!

 Ha pasado un tiempo desde la ultima publicación, y realmente el tiempo se hace menor cuando emprendemos negocios propios, así que, por exceso de trabajo, lo que considero una bendición, no he tendió suficiente tiempo para escribir, además de mis tareas como catedrática, y CIO consultora para dos empresas por horas, y no olvidemos mis tareas como deportista, mama y esposa
 
Pero siempre hay tiempo para lo importante, y hoy quiero publicar un poco sobre mi experiencia personal trabajando en planeación de proyectos agiles y su costeo, antes desde el punto de vista de cliente, y ahora desde el punto de vista de proveedor.
La filosofía ágil y los diferentes frameworks que la representan, son en su mayoría de alta adopción hoy en día en el mundo, con buenas y malas implementaciones, pero definitivamente en la baraja de cartas de casi todas las compañías de desarrollo de software (Y otras también), sin embargo es difícil encontrar un punto mas allá de lo académico en la titánica tarea de presentar un plan de trabajo, unos costos y realizar un contrato en donde ya no se costea por horas, en donde, según estos frameworks, el alcance es variable y desconocido, y por lo tanto, un riesgo financiero y de tiempo tanto del proveedor como el cliente.
 
1.    El método del taxímetro, altamente usado por los proveedores de la región, basa sus estimaciones en horas, lo que significa para el proveedor que entre mas tiempo se tarde, mas dinero cobrara por el proyecto, algo realmente contraproducente para el cliente, y contra producente contra la filosofía ágil en general, pues este tipo de contrato y costeo dificulta el cambio de alcance. Este método es justamente el que inicia las discusiones, eso no fue lo que yo pedí, el producto no es lo que esperaba, cancelemos el proyecto. Como cliente, siempre me sentí estafada con este método, sobre todo porque me cobran por horas de recursos con ciertos perfiles, que ni siquiera se si en realidad fueron asignados a mi proyecto las horas que reclaman.
2.    El método de tiempo y materiales es interesante, pues motiva definitivamente el modelo del alcance variable, en este, se cobra por equipos, no personas, lo cual esta de la mano con los frameworks agiles, por ejemplo SCRUM, pero no maneja la incertidumbre, pues por mas flexibles que seamos, puede que el tiempo no se calcule bien, en beneficio o daño de alguna parte. Terminamos generando miles de cambios de alcances o modificaciones.
 
En la teoría del agilísimo existen dos famosos métodos que también vale la pena describir antes de darles mi opinión y como lo aplico actualmente de forma real mas allá de la academia:
 
1.    Modelo Cockburn: En este modelo, se define un costo por hora de los recursos mucho menor a lo que en realidad le cuesta al proveedor, pero además se estiman unas historias de usuario y unos puntos de usuario basado en los raleases (mediano nivel de detalle), y se asigna un costo por cada punto de historia de usuario. De esta manera:
·     Tarifa horaria base baja, menor que el costo (50 usd), por ejemplo (15 usd)
·     Se define una tarifa por punto de historia de usuario para cubrir el presupuesto del punto 1. (160.000 – 15* 3200) / 1000 = 112 USD
·     Si el proveedor se tarda dos semanas mas del tiempo planeado (320 horas mas), el sobre coste se limita, pues siempre seran las mismas 1.000 historias de usuario, y el costo de las horas adicionales sera a la tarifa base baja = 164.800. En un proyecto tradicional con tarifa de 50 usd, el cliente habria pagado = 176.000 usd
·     Si el proveedor termina antes, Y ESTE METODO LO MOTIVA, por ejemplo termina las 1.000 puntos de historia en 18 semanas, entonces su costo disminuye, originalmente era de 160.000 usd y se reduce a 144.000 usd
 
Este modelo es muy completo, pero en mi experiencia, complejo de explicar a clientes y proveedores, la medida de la cantidad de puntos de historia sigue siendo un voto de confianza. Es teóricamente muy completo, pero personalmente no he podido aplicarlo a proyectos de la vida real.
 
2.    Modelo money for nothing and changes for free: Este modelo supone que la creación de dos clausulas en el contrato, la clausula de money for nothing en donde si el cliente quiere acabar el proyecto antes de tiempo (super alineado con agilísimo) puede hacerlo y se pacta un porcentaje que se pagara al proveedor por el tiempo adicional pactado que ya no se trabajara, y una clausula de changes for free en donde, el cliente puede cambiar cualquier orden de trabajo, puede hacerlo por otra así sea nueva, siempre y cuando tenga las mismas historias de usuario de la que se reemplaza. En mi experiencia, el modelo de money for nothing and changes for free es complejo de pactar pues cliente jamas puede imaginarse un producto con menos de lo que quiere al principio, al contrario, normalmente termina siendo mas que el alcance inicial.
 
Mi recomendación y practica para la estimación de costos y contratos agiles es la siguiente:
1.    Definir un alcance básico, lo que se llama en los niveles de planificación de agilísimo, una VISION.
2.    Definir un ROADMAP con las características de valor y problemas a solucionar en cada uno de los releases.
3.    Con estos dos puntos, crear un costo y tiempo base del proyecto sobre un contrato de tiempo y materiales, por el equipo completo, no por horas, ni por personas individuales.
4.    Durante los ajustes de alcance de realease, trabajar la clausula de Changes for Free para dar flexibilidad al cliente.
5.    Posterior al ultimo reléase, si aun existen requisitos del cliente que se desean cumplir, evaluar si se lanza un nuevo contrato de tiempo y materiales por esos releases (si es algo grande), de lo contrario, y al ya tener métricas de este equipo de productividad, definir cuanto costara al proveedor y definir un precio por entregable, no por hora.

Como construir un BUEN Customer Journey Mapping

Una de las áreas en las que he trabajado los últimos años es en la construcción de journey mappings de clientes, y aunque siempre pienso en la experiencia del cliente como un todo, debo de admitir que la experiencia digital es la que más me apasiona, por lo que este mes quiero hablarles un poco del metodo de ejecucion de un journey mapping según mi experiencia.

Esto no crean lo aprendí de la noche a la mañana, aparte de un par de cursos que recibí en Estados Unidos y una experiencia vivencial en el New York times, he aplicado esto por varios años en distintas empresas, con un mismo objetivo, entender la experiencia del cliente y claro identificar cómo hacerla mejor.

Como se dice continuamente, la experiencia hace una diferencia radical en la decisión de compra de nuestro cliente, ya conocemos el famoso ejemplo que siempre nos citan de starbucks y como preferimos café más caro por la experiencia, pero este ejemplo creo que ya esta demasiado sobrevalorado, sobre todo porque la experiencia de starbucks, al menos en Estados Unidos ya no tiene nada de especial. Así que quiero enfocarme mejor en experiencias digitales diferenciadoras y sobre todo en cómo se construyen desde los journey mappings de clientes.

Quiero empezar resaltando que la empresa no tiene un único journey mapping y que este tiene que cambiar en el tiempo, porque no tiene un único tipo de clientes, y no todos los clientes quieren lo mismo y no lo que quieren es estático, esto es dinámico y cambia constantemente. Ahora, cada tipo de cliente tiene expectativas distintas, y no valora el servicio de la misma manera, por lo que podemos tener distintos journeys, distintos tipos de clientes y distintas ofertas de valor.

Como mencionaba al principio voy a enfocarme en el journey mapping digital por pasión y experiencia, pero el proceso es igual para la ideación de cualquier journey.

Primero quiero presentarles mi kit de journey mappings, que me ayuda a hacer de este ejercicio algo divertido y agregarle un poco de gamification al proceso. Aunque existen herramientas tecnológicas increíbles para hacer estos procesos, sigo creyendo en las herramientas didácticas como catalizadores de un buen trabajo en equipo, así que aunque soy una persona “digital first”, en este caso me quedo con mi juego de mesa:

1. Como suelo iniciar este tipo de ejercicios: Siempre recomiendo iniciar rompiendo el hielo hablando un poco de experiencias como clientes de los participantes. Vamos a notar que en este momento, casi siempre, los participantes nos comentan malas experiencias o por lo menos son los momentos en donde detallan más su experiencia. Siempre tendemos como humanos a recordar más las cosas malas. De esa misma forma nos recuerdan nuestros clientes.
2. Una de estas experiencias es elegida y hacemos un pequeño journey mapping usando desde el principio el material de apoyo, es más fácil ser sinceros y describir el viaje cuando hablamos de una empresa tercera que no somos nosotros.
3. El ejercicio rompe el hielo pero sobre todo me permite explicar a los participantes el método de journey mapping, el objetivo y porque estamos haciendo esto para nuestra empresa. Esto por experiencia funciona mucho mejor que tratar de explicar el método y entrar en frio a analizar la experiencia de nuestro cliente, sobre todo porque esta es generada por nosotros mismos, y ser autocríticos no es una de las cualidades más fuertes de los seres humanos.
4. Posteriormente junto al equipo describimos el viaje del cliente digital hoy en dia. En esta parte del ejercicio siempre sucede que los participantes del equipo tienen ideas de viajes distintos. El comercial cree que sucede una cosa, el de tecnología otra, el CEO otra. Y más adelante descubriremos que el cliente percibe algo totalmente distinto.

Mi recomendación es, basado en datos, para evitar percepciones, datos que ya debo de llevar preparados a la sesión, dejar que el equipo pueda entender el viaje real que se vive, tiempos de respuesta, canales de comunicación, reclamos de los clientes. Suele ser el momento más tenso, y por eso, les dejo algunos tips para manejarlo:

4.1 Cuando dos áreas no están de acuerdo, por ejemplo el gerente comercial asegura que el tiempo de atención de un cliente potencial digital es de 3 horas pero el CEO le menciona que algunos amigos suyos que han sido clientes tienen otra percepción, rompamos la discusión primero evitando los casos puntuales y segundo basándonos en los datos, ¿que nos dice la estadística sobre esto?

4.2 Alejemos las discusiones de roces que ya pueden existir entre las áreas, usando la gamificación y evitando conflictos, que no aportarán mucho al ejercicio. La discusión es bienvenida, siempre que se enfoque en la experiencia del cliente, sea relevante y aporte valor. Usemos el método del “parqueadero” para congelar temas que no son relevantes al ejercicio.

5. Ya con el “Customer Journey” descrito actualmente, empezamos a hablar de las posibilidades a futuro. Podemos usar una base de quejas de clientes si ya la tenemos, o podemos invitar a algunos clientes a que nos den su posición sobre ese viaje actual y cuales son las experiencias que no satisfacen sus expectativas. Esto al final nos permitirá diseñar el viaje futuro, el deseado por nuestro cliente y no por la comodidad o limitaciones de lo que ya conoces de la empresa. Es importante en este punto mantener al grupo alejado de controversias como, “Eso yo ya se los había dicho”, “ eso ya lo intentamos”, siempre regresemos al equipo al foco de pensar como clientes sin restricciones, sin barreras, sin pensar en lo que el sistema de tecnología permite o no. Eso es algo que se valida posteriormente en la etapa de definición de alcance del proyecto de transformación digital de experiencia del cliente, pero en este ejercicio que estamos describiendo, lo que se vale, es soñar.

6. El journey futuro normalmente es la parte más bonita del ejercicio, pues el equipo se permite soñar y es donde nos damos cuenta que al final todos deseamos lo mismo, un mejor proceso que haga de la experiencia del cliente algo diferenciador, y que también, hará más sencillo nuestro trabajo.

Qué esperar de este ejercicio:

• Que entregamos al final de este ejercicio, bueno pues entregamos el “journey” actual del cliente y el “deseado”. Además de la viabilidad de implementación del deseado, evaluando con ejercicios de arquitectura empresarial la situación actual y futura de cultura, procesos y sistemas.

• Un plan de implementación por fases, junto a un listado de métricas que deben medirse e impactarse según estas transiciones entre el “journey” actual y el deseado.

• Un listado de responsables y la definición de un equipo multidisciplinario (CoE) que permita hacer realidad lo construido en el taller.

En qué situaciones un “journey mapping” genera valor en mi empresa:

• Estás viviendo una unión o adquisición de otra empresa y quieres asegurarte que tu cliente realmente perciba valor de esta nueva unión.

• Estás pensando en iniciar un proceso de transformación digital

• No tienes aún definido o quieres clarificar la experiencia de tu cliente con tu producto y proceso.

• Quieres poder hablar de experiencia y oportunidad de mejora en procesos con tu equipo de trabajo sin generar un ambiente de conflicto

• Crees que la experiencia de tu cliente hará una diferencia en tus métricas de ventas, lealtad, retención, etc.

Te interesaria una prueba de un journey mapping gratuita en tu empresa?

Déjanos tu contacto en un comentario.

Una arquitectura compleja usando AWS

No podía cerrar mayo sin publicar una entrada. No he tenido el suficiente tiempo pues he estado dedicada a varios proyectos, y claro a estudiar, pues estoy preparandome para certificarme como Amazon architect. Asi que, decidi en honor a la mejor clase que he recibido hasta ahora, y también como un buen ejercicio para repasar, publicar hoy una arquitectura en Amazon Web Services usando tres capas y compartirles un poco de cómo he aprendido que todo esto se relaciona.

Vamos a suponer que tengo un requerimiento, la creación de un sitio web con un carrito de compras para clientes que desean comprar licores y pinturas. Este es un sitio web que permite no solo la búsqueda de productos, sino su compra y despacho, funciona únicamente para clientes finales personas naturales o B2C si así queremos llamarlo.

Se espera que el sitio de comercio electrónico reciba visitas de distintas latitudes en el mundo, se espera que sea rápido en su rendimiento y seguro (como todos los requerimientos de los usuarios jajajaja). Además se solicita que este disponible 99.999% del tiempo y que maneje estrategias que permitan que esto suceda, al final son productos que se adquieren 7x24.

Ahora vamos a suponer que ya soy una arquitecta amazon certificada y que debo de definir la arquitectura a usar para esta aplicación. Algo que ha funcionado para mi es empezar pensando en la estructura más sencilla de la solución y luego ir haciendola robusta hasta que considero que cumplira los requerimientos de mi cliente final. Así que iniciaré cumpliendo con el primer requisito, un sitio web que permita tener un carrito de compras:

1. Arquitectura número uno:

A.  En esta arquitectura consideraré entonces un EC2 instance o en otras palabras un servidor en donde desplegará mi sitio web transaccional. (Si fuera solo estático podría considerar un bucket de S3 pero no es el caso). Este servidor, según las métricas entregadas por el cliente puede ser de la familia M3, no necesito más. (las familias definen entre otras cosas la capacidad del servidor, memoria, espacio, I/O, etc).

B. Debo tener almacenamiento para poder tener cuentas de clientes que compran, así que agregare una base de datos, en este caso usare RDS que es el servicio de bases de datos relacionales de AWS. Además he decidido desplegar una base de datos en Aurora, motor propio de AWS que ya por su propia cuenta maneja temas como réplicas, disponibilidad, entre otros. (Un poco mas caro pero el mantenimiento, crecimiento será más sencillo).

C. En términos de seguridad quiero que solo mi servidor EC2 sea accesible desde internet, por lo que mi instancia de Aurora la creó dentro de una subnet privada y creo permisos de acceso únicamente a el servidor en donde alojo mi sitio web. Además agregó RUTA 53, esto no es más que un DNS para los servicios de AWS. Finalmente asignó a este servidor web una ip elastica para que en caso de cambiar la ip publica no tener problemas de direccionamiento. Al final mi arquitectura se veria mas o menos así:

2. Mi segunda arquitectura ya será un poco más completa pues aunque ya tengo un sitio web, aun tengo requerimientos de seguridad, disponibilidad, cantidad de transacciones y rendimiento que debo cumplir.

1. Primero para la alta disponibilidad y tolerancia a fallos definitivamente NO puedo tener un solo servidor EC2 instance ,y cómo a diferencia de aurora, la alta disponibilidad no está por defecto, debo configurarla. Para esto necesito entonces agregar un balanceador de cargas que entre otras cosas incluye un health check, este me permitirá asegurar disponibilidad y saber si alguna instancia está “muerta”, además para tener acceso desde distintas regiones desplegare estas instancias en MutliAZ ósea en distintas zonas de disponibilidad o distintos data center en distintos lugares del mundo si así queremos llamarlo.
2. Si tengo los servidores y las peticiones distribuidas tengo que lidiar con un nuevo “requerimiento”. Si un cliente lanza una petición por ejemplo y crea un carrito de compras, quiero asegurarme que este quede disponible la próxima vez que el cliente entre, y que pueda visualizarse si su nueva petición ya no viaja al mismo servidor (Si quisiera que viajará al mismo servidor puede configurar stickiness pero esto no me gusta para el nivel de disponibilidad porque qué pasa si justo esta instancia se cae) asi que mejor colocare un elasticache, en donde almacenar el carrito de compras de todos los clientes que visiten el sitio.
3. Voy a eliminar la elastic ip, pues ya no es un solo servidor, mejor configurar un alias en el Route53 que me direccione al balanceador de cargas, que además por seguridad será el unico desplegado en una subnet publica, ahora tanto mis máquinas EC2 como mi capa de RDS estarán en subnets privadas solo accesibles desde el balanceador o entre ellas.  
4. Finalmente, incluiré read replicas para Aurora, esto con el fin de que todo lo que el sitio requiera en términos de lecturas así como toda la reportería que implementará proximamente apunte a estos servicios y así no generar problemas de disponibilidad.

Mi arquitectura final se veria mas o menos así:

Como todas las arquitecturas existen miles de opciones distintas de cumplir los requerimientos de mi cliente, pero esta seria mi solucion final a plantear. Al final de este ejercicio y de lo todo lo que he estudiado he llegado a la conclusión que AWS me permite realmente por primera vez relacional atributos de calidad, conceptos de arquitectura de software con el despliegue final de las soluciones. Definitivamente Cloud es el cómo.!!!

El diseño, todo un protagonista de la era digital!!!

Este mes me ha sido un poco difícil elegir un tema en particular para mi entrada, pero aprovechando un tema del que hablare en los próximos días en una charla, pensé que conversar un poco del diseño grafico y su impacto en la experiencia de usuario, sobre todo considerando que esta experiencia hace una total diferencia en la eficacia de una solución digital que se implemente.

Como muchos saben yo he estado trabajando por años en las transformaciones digitales de empresas, apoyándome en métodos como la arquitectura empresarial y la aplicación de agilismo para ayudar a las empresas a dar pasos hacia adelante en un claro mapa de transformación, pero si hay algo de lo que he dependido y definitivamente no domino, es la experiencia de usuario. No lo domino porque no es mi materia, y la experiencia me ha permitido entender que, asi como todo lo demás en la vida, la primera experiencia es la mas importante, y esta siempre entra por los ojos. Es por esto que acompañado de un excelente proceso de transformación y de excelente tecnología de apoyo debemos tener una clara línea de experiencia, de diseño, que acompañe el proceso y que permita que excelentes sistemas, campañas, promociones, vayan de la mano de una experiencia al cliente que le permita en realidad usarlas, encontrarles valor y apreciarlas, de lo contrario, ¿Para quién estamos transformando?

Normalmente hablo de personas, procesos, sistemas…hoy quiero hablar de experiencia. Y frente a las soluciones digitales la experiencia hace una total diferencia, puedo citar varios ejemplos, en donde la experiencia que el diseño de la solución entrega al cliente final es relevante. ¿Han tratado de pagar un servicio en el pago en línea de claro sv?, porque para mi es una pesadilla, es confuso, las pantallas tienen tanta información, quieren simular un carrito de compras, pero no lo es, es difícil el flujo, complejo, alejado de un “one-click-experience”. Han intentado encontrar un producto en la pagina de farmacias san nicolas?. Yo creo que seguramente detrás de esas paginas tienen excelentes sistemas de inventario y facturación, pues cuando voy a la farmacia en persona siempre pueden rápidamente contestarme la existencia de un medicamento en esa tienda o en una sucursal, ¿Por qué es tan difícil en línea? Pues yo entendería que el sistema y la información ya está. En mi concepto todo radica en la arquitectura claro, el diseño de como usar esa información, pero la gran diferencia entre sí puedo usarlo o no radica en el diseño, por eso aunque sea muy digital, aun llamo por teléfono para pedir los medicamentos y tengo un mal concepto del viaje digital de estas empresas. Quiero citar un ejemplo positivo, la experiencia digital de la aplicación Hugo, cumple lo necesario, es sencilla de usar, los botones están donde yo creo deben estar,  y no debo hacer ningun tutorial para ser capaz de usarla, un bravo para los diseñadores. Al final el diseño es no solo la clave para que la transformación digital penetre a los usuarios sino para que la resistencia interna sea vencida, puedo construir una excelente plataforma nueva, pero si no es fácil de usar, sino es intuitiva, mi usuario interno preferirá seguir en su sistema viejo pero conocido, en esta época, cualquier sistema que requiera un manual de usuario, este acabado, empezando porque las personas ya no leen. Lo grave es que muchas empresas siguen confiando esta parte a los que somos de “informática”, cuidado, nosotros no somos expertos en esto, o si no, revisen nuestro estilo de la moda para que lo verifiquen.

Dejemos de lado el aporte del diseño en la construcción de soluciones y enfoquémonos en el marketing, la diferencia que genera en las campañas publicitarias modernas las artes y los mensajes que transmiten, el cambio de caligrafías fuertes a letras cercanas, en esta época de “deshumanización” una letra mayúscula o minúscula hacen una diferencia inmensa en lo que se transmite al cliente y recordemos, cuando la interacción humana disminuye, lo que logremos transmitir a través de la pantalla del celular es lo que el cliente conocerá y pensara de nosotros, tenemos que transmitir sentimientos a través de las palabras, las imágenes, los colores, eso nos posicionara como una marca cálida o una marca fría y apartada. Ya no es solamente pensar en construir un arte que se imprima en un flyer y motive a mis clientes a visitarme para mas detalles, tengo que construir un arte que permita que mis clientes potenciales compren conmigo, porque ese arte será toda la interacción que tendremos jamás.

Ahora pensemos en los atributos no funcionales de una aplicación, en donde el tamaño, el peso, la forma como se despliega una imagen en una solución de una pagina web por ejemplo hace toda la diferencia en el tiempo de respuesta y experiencia, no solo debemos hacer diseños que sean cercanos al cliente, que transmitan la visión de nuestra marca sino que además deben ser óptimos, no estamos dispuestos a esperar que cargue una imagen hermosa por mas de 2 segundos, para ese momento el bounce rate de nuestra página estará creciendo abruptamente. No es lo mismo diseñar para un periódico que para un medio digital y nuestros queridos diseñadores deben estar conscientes de esto.

Quiero finalizar simplemente concluyendo que esta profesión es cada vez mas importante para los procesos de transformación, que deben ser cada día mas aliados de nosotros los que hacemos el back por asi llamarlo, aunque ustedes nos pidan cosas que son imposibles, y nosotros hagamos cosas que funcionan pero son estéticamente horribles, debemos dejar de lado esos prejuicios, zapatero a tus zapatos, al final lo importante es el cliente, y el necesita de ambos, buenas soluciones, que además de ser confiables, sean usables y agradables. A unir fuerzas señores.!!!

El arte de diseñar soluciones tecnologicas

En este mes quiero dedicar un espacio para explicar a detalle que es la arquitectura de software y como se ve el trabajo de un arquitecto de software en la vida real, más allá de la teoria y aplicada a las empresas reales que tienen una real arquitectura de software. ¿Por qué usar tanto la palabra real?, porque la arquitectura es uno de esos términos ampliamente usados, y en esta región, en muchos casos y para pesar de quienes somos profesionales en esta área, mal usado y mal interpretado por perfiles tanto técnicos como administrativos de las organizaciones. Hablemos entonces con un ejemplo que se aleja de la tecnología sobre la arquitectura de software, las capas o tipos que tiene, así como su evolución en el tiempo.

Para empresa quisiera hacerles una pregunta que espero contesten para ustedes mismos antes de continuar. Usted tiene el proyecto de construir una nueva casa a su gusto, está considerando nuevas características que requiere pues ahora con dos hijos pequeños, mascotas y a su padre viviendo con usted, las necesidades que tenia cuando compro la casa donde vive ahora han cambiado. Usted requiere alguien para transmitirle las ideas y que pueda hacer un plano de todas sus necesidades y asegurarse que sea estéticamente correcto y estructuralmente también, que considere su presupuesto, su visión a futuro, tal vez una piscina mas adelante con un área de juegos. ¿A que profesional contrataría? (Si alguno quiere dejarme su respuesta en los comentarios es bienvenida).

Pues la respuesta más común es, a un arquitecto. Y es que en el negocio de la construcción esta claramente separado el concepto de arquitecto, así como están el de maestro de obra, constructor, albañil, etc. Lastimosamente esa línea en la tecnología no esta bien definida, en gran parte, por culpa de nosotros, los profesionales en esta área que tampoco la tenemos clara.

Entonces, que es la arquitectura de software: No es otra cosa que un conjunto de patrones que proporcionan un marco de referencia para guiar la construcción del software. Esto quiere decir que para hacer un software TAMBIEN se hacen planos. Ahora, y donde nosotros los que estamos en esta profesión pecamos es en creer que cualquier diagrama con flechas es una arquitectura de software, además tenemos que diferenciarla de la arquitectura de soluciones o de integración por ejemplo. Les quiero mostrar algunos diagramas que he visto con el titulo de arquitectura de software:

               

No solo son incorrectos, sino que no existe un único diagrama para describir una arquitectura, existen distintas vistas que permiten en realidad diseñar un software, como el modelo de 4+1 views de Kruchten por ejemplo. Claro, estos modelos algunos demasiado teóricos se alejan de lo que debería de hacerse realmente en una organización, y como todo no es una receta mágica, pero puedo compartirles cuales son aquellas vistas de una solución tecnológica que generan más valor:

1.       Diagrama de arquitectura de solución: Este diagrama permite entender la solución como un todo, mostrando normalmente componentes tecnológicos como cajas negras. Este es un diagrama muy general que por si solo no expresa la totalidad de una arquitectura. En este tipo de diagramas pueden evidenciarse patrones de alto nivel como, patrones de integración, patrones de consumo de datos, etc.

2.       Diagrama de arquitectura de software: Normalmente este describe como esta construido un sistema, y evidencia su patrón de arquitectura, podemos observar mas de uno, alguna parte con tubos y filtros, otra usando algo tipo MVC o en capas, etc. Este debe describir todos los componentes a alto nivel de un sistema y sus interrelaciones. Y es este uno de los que menos he visto en los últimos años, pues ya nos acostumbramos a pintar nuestras soluciones tecnológicas como cajas negras y a dejar por dentro aun códigos monolíticos corriendo sobre “Arquitecturas de últimas tendencias”, esto sobre todo por temor a decir que aun nuestra arquitectura, en la nube y todo en muchos casos, sigue siendo monolítica. Es así como nos atrevemos a construir un conjunto de apis usando por ejemplo .net y hacer que estas no sean mas que fachadas que en realidad siguen invocando un sistema monolítico, entonces la velocidad, independencia y posibilidad de desplegar las apis como verdaderos microservicios se pierden, pero claro, esto no lo vemos en un diagrama general de cajas negras, es así como quienes no conocen esto a profundidad son engañados por las nuevas invenciones y “evoluciones” de sus contextos tecnológicos.

3.       Diagrama de arquitectura de infraestructura: Este diagrama muestra todo el mapa a detalle del contexto de hardware que ayudara a soportar la solución de software, y siguen necesitándose así la solución este en la nube, es bueno saber, por ejemplo de ser una solución Amazon, en que tipo de instancias estas desplegado, como usaste los módulos EBS de persistencia entre otros, además de los componentes de red, luego no nos asombremos cuando implementamos un software  y no funciona al inicio pues se nos olvido abrir puertos en el firewall entregar permisos entre otros, ese tipo de solicitudes se visualizan con este diagrama.

4.       Diagrama de despliegue: Es importante siempre poder relacionar el hardware y el software y este diagrama lo permite, identificar que esta desplegado en cada componente de infraestructura y como están conectados, protocolos, seguridad entre otros.

5.       Diagrama de integración: Ha tomado muchísima relevancia con los nuevos esquemas de integración y la desaparición de los sistemas (todo en uno), ahora prevalece el tener pequeños componentes de software que se conectan y por lo tanto tener un diagrama que permita conocer esas interrelaciones y acceder a los contratos o descripciones de métodos y variables entre las integraciones es fundamental, esto puede administrar por ejemplo de ser el caso usando un api management. Además si está usando microservicios contenerizados, le permitirá junto al diagrama anterior, entender como están desplegados sus microservicios y en que contendedores y donde residen.

6.       Diagrama de Arquitectura de datos: Y ojo que esto no es el diagrama entidad relación, es más, en esta entrada no estoy para nada hablando de diagramas de diseño detallado, eso puedo tocarlo después, estoy hablando de la descripción de sus fuentes de datos, gobierno de información, migración de data histórica, etc. La data hoy en día es lo que finalmente más valor genera, pero es raro ver a un “arquitecto” diagramando esta vista.

¿Parece mas complicado que pintar cajas negras o servidores con flechas?, claro que lo es, por eso es arquitectura, por eso es una profesión especifica dentro de la rama de tecnología, por eso no todos podemos simplemente hablar de las arquitecturas si no tenemos claro que son los patrones, que son los atributos de calidad y como funcionan en son de las arquitecturas y de las necesidades del usuario. También debemos como profesionales ser sinceros y decir lo que tenemos y lo que no tenemos, si construimos un “microservicio”  que invoca 5 procedimientos almacenados de una base de datos, la cual funciona con una arquitectura monolítica no estoy haciendo microservicios, es más ni siquiera podre desplegarlos en un contenedor, debemos de dejar de usar los términos de manera incorrecta, vender información falsa, llenar la cabeza de nuestros CEO’s con datos incorrectos que después frente a una sala de personas expertas los harán quedar como unos ignorantes en el tema. Las arquitecturas de software así como las arquitecturas de las casas han evolucionado, pasamos de sistemas monolíticos a arquitecturas orientadas a servicios y ahora estamos hablando de microservicios, no todo aplica para todos y no todo debe hacerse por ejemplo con microservicios porque es lo último. Pero tampoco es cierto que, si a su casa de los años 20 le cambia la pintura de la fachada, sus cimientos y tuberías no seguirán siendo de los años 20.

Por favor, para hacer arquitectura de tecnología, así como lo haría para su casa, contrate a un arquitecto de tecnología, esto hace diferente que sea tan difícil hacer un cambio en un sistema, o que para hacer un cambio debe hacerse en la madrugada porque hay que apagar todo  o que cuando corren procesos grandes todo se pone lento, o que cuando se va a hacer algo nuevo debe de lidiar con la obsolescencia y problemas de lo viejo, es lo único que asegura software de calidad, testeable, durable, escalable, adaptable… moderno!!!

¡¡¡Feliz semana!!!

La gran ganadora.. LA ERA DIGITAL!!!

Alejándome de todo el tema político porque no es algo de mi dominio ni es un tema para discutir en mi blog, quiero hacer un poco de análisis sobre los resultados electorales en el estricto sentido de las estrategias de campaña tradicionales vs las digitales, y como en un país como El Salvador, que es menospreciado por algunos ciudadanos, en donde se cree que eso de la tecnología esta aun muy lejos, y somos muy tercermundistas, un Facebook live tuvo mas asistencia que un debate en televisión nacional. ¿será que en realidad aún estamos lejos de la tecnología o no será más vale que a muchos les está costando entender que la resistencia no es invencible y que nuestro pequeño país en realidad está cambiando?

Le pido por favor que si va a hacer algún comentario sobre el articulo para exaltar propuestas de algún candidato, o relatar historias del pasado de otro, no es esa la intención, aca solo quiero que hablemos de la campaña digital que venció en todos los sentidos, incluido el sentido ambiental, a la campaña tradicional que regala banderas en los semáforos.

En mi vida laboral me enfrento diariamente a la incredulidad del mundo digital y sus implicaciones en el corto y mediano plazo en nuestro país y en la forma como hacemos las cosas. Eso es algo nuevo y exploratorio me dicen, nunca se debe dejar de entender que los canales tradicionales son los que mas venden, lo otro es como un hobbie para los millenials, pero las personas tradicionales que son quienes tienen el dinero (entre 30 y 50 años) prefiere lo tradicional que ya conocen. Bueno señores, quiero decirles que esta campaña política que además se quedó con la presidencia del país les dijo “ESTAN EQUIVOCADOS”, aunque obvio, sé que la mayoría aun no quiere verlo.

Empecemos por el dato demográfico de los electores en el país:

Se consideraría entonces que quienes eligen en su mayoría están entre los 30 y 59 años, ¿son millenials la mayoría de electores?. Sin embargo, durante la campaña tuvo más peso una comunicación abierta y continua por redes sociales, ausentarse de las típicas propagandas, de los letreros que contaminan las ciudades, no repartieron ni una sola bandera (o yo no las vi), lo que si vi y debo aplaudir de la campaña, en términos digitales nuevamente:

1.       Transmision por Facebook live dándole acceso a todas las personas en todos los lugares.

2.       Un plan de gobierno publicado en línea, con una pagina web enriquecida y con suficiente contenido, además de espacios de opinión digitales.

3.       Un trabajo fuerte de promoción, y de presencia en redes.

4.       Un cambio de marca y logo que hizo que todos olvidaran la marca real por detrás del ganador.

5.       Una imagen moderna, joven, sin corbatas ni los típicos formalismos

6.       Una cercanía digital por medio de comunicados específicos en donde se tocaban los dolores de la población en vez de visitas y fotos abrazando a cuanto elector encontraban

7.       Encuestas digitales

8.       Comunicación constante por redes de situaciones laborales y personales que generaron en las personas una sensación de cercanía y de conocer realmente a la persona detrás de la cuenta de Facebook.

9.       Etc.

¿Sera entonces señores que en realidad estamos tan lejos en nuestro país del primer mundo digital? ¿Sera que esto es algo para los millenials no más? Mi conclusión después de esta campaña es que no es el pueblo quien esta lejos, son aquellos con poder que temen el cambio que siguen negándose así como le paso a los partidos tradicionales, los que siguen pensando saber lo que lo clientes quieren y siguen haciendo lo mismo, los que siguen esperando llegarle a sus clientes de la misma forma que antes, los que siguen pensando que la lealtad se compra con regalos, o regalando abrazos fingidos, los que niegan una realidad que hoy en día tiene la capacidad de darle hasta la presidencia a una campaña digital.

Feliz semana

¿Que es todo esto de arquitectura, y los distintos roles solicitados por las compañias?

Aprovecho una publicación que vi en estos días en linkedin y en la que participe con un comentario, para hacer mi publicación de este mes, en donde les daré un poco de mi visión sobre los roles de arquitectos de software, de soluciones y empresarial, términos altamente usados, y en mi forma de pensar, muy mal usado últimamente.

1.       ¿Qué es un arquitecto empresarial?: Elijo empezar por este, pues es tal vez el rol en que mas me he especializado en mis últimos años laborales. Es un perfil difícil de explicar y creo que se convirtió en una visión de “subir de nivel” de muchos arquitectos y por eso mismo muchos empezaron a auto-proclamarse en este nuevo concepto de “moda”.

La arquitectura empresarial en mi opinión es un método, una forma en la que las organizaciones pueden orientar todos sus esfuerzos en un objetivo común o arquitectura “to Be”. Pongamos un ejemplo: La empresa ACME esta pensando en que es momento de digitalizar algunos de sus servicios hacia el cliente final y para esto tiene distintos proyectos en una lista entregada por un consultor, debe implementar un sitio web transaccional, una aplicación móvil, automatizar algunos procesos usando un bpm, debe realizar un proyecto de transformación cultural para que exista una nueva cultura digital en la empresa y al final como objetivo debe vender mas y crecer en clientes explotando estos nuevos canales. ¿Por dónde empezaría usted? ¿Cómo organizaría los proyectos? ¿Cómo mediría el logro de los objetivos planteados?

Arquitectura Empresarial ha sido un método que personalmente he usado durante los últimos años para darle forma este tipo de ejercicios corporativos que van más allá de administrar proyectos, y que tocan definitivamente aristas de procesos, personas y tecnología. Un buen arquitecto empresarial tendrá entonces la capacidad de diagramar y explicar la situación actual de los elementos que serán impactados por estos cambios en términos de software/hardware, pero también en términos de procesos de negocio y personas. Debe también construir un estado futuro o “to-be” basado en los proyectos a ejecutar y en la visión a largo plazo (en este momento puede identificar otro grupo de proyectos que no se habían identificado antes) y para esto se usa el change management y la fase de oportunidades y soluciones si es que el arquitecto aplica un framework como TOGAF.

Posteriormente, con estados actuales y futuros, puede identificar transiciones y estas pueden priorizarse según por ejemplo el valor generado, o hacer lo más rápido primero (quick wins), eso depende de cada empresa y cada arquitecto, pero al final, plantea un mapa de transiciones que permiten visualizar como va avanzando la organización hacia los objetivos señalados. Es un constructor de ruta en esa fase, que permite además validad constantemente el alineamiento de los objetivos con lo que se esta trabajando y con la visión de la empresa. Es además siempre un evangelizador de los procesos de transición de las empresas, un mediador, por esta razón en muchos casos es un perfil optimo para procesos de transformación digital entre otros rubros.

Debe el arquitecto empresarial saber programar, pienso que siendo purista no, no es necesario ni es su rol. No simplemente por ser un buen programador te haces arquitecto de software, ni por ser arquitecto de software un buen arquitecto de soluciones, ni por ser un buen arquitecto de soluciones entonces eres un buen arquitecto empresarial, no es una escala de ascenso son roles diferentes.

Ahora, programar es siempre una gran ventaja competitiva, porque más allá de saber escribir líneas de código, asegura tu capacidad mental estructurada para solventar problemas y organizar soluciones, una cualidad clave para cualquier arquitectura y para cualquier profesión, por lo que saberlo siempre es un plus, pero no es el rol necesario ni un conocimiento que un AE deba dominar.

2.       ¿Qué es un arquitecto de soluciones?: Yo siempre he visto a los arquitectos de soluciones como unos traductores de necesidades, pues son capaces de saber de todo, comprender los conocimientos técnicos necesarios, pero también entender las necesidades de negocio. Es un rol que debe tener conocimientos técnicos, pero no necesariamente de programación pues no todos los problemas se solucionan programando. Por lo que debe conocer el contexto técnico de la solución que esta planteando, si la solución es software, pues si, debe saber mucho de programación, de infraestructura, de la nube, de un método de trabajo con devops, de una aplicación de agile, entre otras cosas. Se encarga entonces de mapear la solución end-to-end de un problema. Volvamos a nuestra empresa ACME, ahora que ya tenemos la arquitectura empresarial del punto uno, debemos definir técnicamente por ejemplo con un arquitecto de soluciones, como nos aseguraremos de que la primera transición de la vista de aplicaciones se concrete de una forma adecuada. Si por ejemplo esta empresa como parte de su primera transición identifica la necesidad de construir una aplicación móvil, este arquitecto debe asegurar el diseño de este componente dentro de los componentes ya existentes y de validar que pueda convivir de manera adecuada, que se consideren todas las implicaciones, que se considere el contexto de infraestructura de la empresa, y sobre todo que, si solucione el problema (de acá su nombre), entre otros. Es el que se asegura que esos nuevos componentes encajen en lo existente, y que la armonía y funcionamiento esperado se alcancen.

3.       ¿Qué es el arquitecto de software?: Lo primero y mas importante para mi es diferenciar este rol del rol de líder técnico, porque un líder es justamente eso, quien lidera, y honestamente no todos los arquitectos de software son los mejores líderes. Para aclarar esta definición, creo que los vendedores de software la tienen clara, siempre que te visitan llegan con su vendedor del área de ventas lógicamente, y con su arquitecto de software, que es el apoyo técnico que esta para contestar tus preguntas más específicas. Y es que le arquitecto de software debe dominar un producto(s) técnicamente. Debe dominar además su diseño técnico, los patrones de arquitectura usados, como se despliega de manera optima en la infraestructura y obviamente debe ser un maravilloso programador, y dominar todas las aristas tecnológicas de su(s) aplicaciones, desde la capa de datos hasta la capa de presentación. Es por lo tanto posible que el arquitecto de software programe y considero que definitivamente debe saber hacerlo, de lo contrario va a dar opiniones y diseñar sin fundamentos. Ahora, nuestra empresa ACME identifica como uno de los proyectos para esta transición la necesidad de una aplicación móvil como mencione en el punto 2, el arquitecto de soluciones ya construyo un mapa general y encajo esta nueva pieza, pero ahora debemos hacer un zoom a esa nueva pieza y definir cómo será construida. Este es el rol en donde el arquitecto de software brilla, puede que no sea el líder del equipo porque en ACME se ha implementado un modelo de trabajo usando SCRUM como guía, por lo que el SCRUM MASTER esta liderando al equipo, pero el arquitecto de software tiene un papel fundamental en el equipo pues es quien construirá los planos de la aplicación móvil, y seguramente intervendrá en el proceso de desarrollo. No necesariamente es el MEJOR de todos programando, eso es otro concepto erróneo, pero si es una persona con unas capacidades técnicas sobresalientes y de convencimiento de equipo, pues, si su diseño no convence a los programadores, todos sabemos que ellos terminaran haciéndolo como lo consideren adecuado, todos, todos los ingenieros en sistemas somos tercos y arrogantes.

Una vez me preguntaron si un arquitecto puede hacer los tres roles, yo considero que sí, depende el tamaño de la empresa y del proceso, porque créanme cada una de estas cosas son grandes cantidades de trabajo si quieren hacerse bien y de verdad. También alguien me dijo si ser arquitecto de soluciones era “mas” que ser arquitecto de software, en mi visión no, simplemente son cosas diferentes.

Seguramente muchos no estarán del todo de acuerdo con esta publicación, la arquitectura sobre todo en tecnología ha sido una discusión de alcances, por lo que al final cada quien lo interpreta y lo ajusta a sus necesidades, lo importante es saber que todos estos roles son fundamentales para llevar a cabo procesos de construcción de tecnología y transformaciones de todo tipo en las organizaciones, es como ya lo dije en una entrada pasada, la diferencia entre comprar tecnologías porque si, a tener un real road map de transformación, un conjunto de roles que de ser ejercidos por las personas correctas con las habilidades adecuadas, aseguran que usted tenga un mapa adecuado y ordenado, unas inversiones que en realidad solucionen sus problemas y en caso de requerirse software, tener la certeza de la calidad de su diseño y durabilidad en el tiempo.