2do Encuentro de Arquitectura de Software en Mar del Plata

Agenda del evento

La idea va tomando cuerpo, se llevó a cabo un segundo encuentro y hubo una gran audiencia. No era para menos, recibimos a Alejandro Bianchi presidente de Liveware, un experto en Arquitectura de Software; a Ignacio Peña VP of Technology de Globant y a Diego García. CTO. de Lateral View.

Este encuentro tuvo como epicentro Arquitectura y Agile, dos conceptos muy fuertes en el desarrollo de software, que según con quién hablemos, pueden verse como complementos o contrapuntos. Con las charlas que presenciamos, vimos como con todo lo que sucede en el marco de la arquitectura, ese balance entre ambos conceptos es un trade-off más con el que tenemos que lidiar y no existen recetas; existe conocimiento y experiencia.

Abrió el evento Alejandro, su presentación tuvo una parte introductoria de lo que encierra la disciplina de arquitectura, algunos de los conceptos que siempre repetimos como los atributos de calidad, epicentro del diseño de arquitectura. Pero rápidamente ubico a la arquitectura en el contexto actual, cuales son las tecnologías que hoy marcan tendencia y determinan el rumbo de las industrias nuevas y tradicionales. Internet de las cosas, cloud computing, microservicios, blockchain y sobre todo el concepto de digitalización de la empresa.

Por qué decimos “sobre todo”, porque la digitalización hoy domina el mercado, digitalización desde un concepto mucho más amplio que cambiar papel por bytes, es digitalización como una nueva propuesta de valor.

Este marco nos lleva a que IT debe desarrollar nuevas habilidades, nuevas capacidades y Alejandro propone como tesis que el rol del arquitecto en este marco es esencial y crítico.

Es así que la presentación pasa por como se mixan las habilidades blandas del arquitecto con técnicas, la negociación constante entre la metodología y las demandas actuales de vertiginosidad, ciclos de vida más cortos y agilismo. Es importante incorporar el concepto de que tanto para Agiles como para la Arquitectura prima por sobre todas las cosas la satisfacción del cliente. Es allí donde Alejandro nos muestra coincidencias muy claras entre principios del agilismo y la arquitectura.

La presentacion abarcó también un tema importante como la deuda técnica y su gestión. Tema que hemos hablado en el evento anterior y recalcamos siempre. La deuda técnica existe, debe ser gestionada pero por sobre todas las cosas buscamos que sea algo conciente, debe ser una decisión tomada no una situación encontrada.

Nos quedamos con gustito de más, se mencionó devops y es un tema que nos interesa, esto es simplemente una captura de lo que fue la charla; acá les dejo la presentación de Alejandro para que puedan desmenuzarla aún más.

Presentacion Alejandro Bianchi

Luego de la presentación de Alejandro presentamos el grupo ArqConfMDQ, fundamentalemente con el objetivo de poner una visión en común:

En ArqConfMDQ queremos fomentar el conocimiento aplicado al diseño de software. Buscamos compartir experiencias que ayuden al desarrollo profesional de las personas y empresas de la región. El marco de esta comunidad comprende fomentar estándares, buenas prácticas, novedades, debatir sobre ideas, herramientas y técnicas. También esperamos que sea un lugar para juntarnos a estudiar nuevas metodologías, colaborar y probar tecnologías existentes y socializar soluciones. Un lugar en el que el conocimiento se comparta para lograr un mundo mejor para todos.

con un interés:

Lograr un desarrollo del conocimiento en Arquitectura de Software que contribuya el posicionamiento de Mar del Plata como polo tecnológico en el plano internacional.

Este meetup propone diferentes dinámicas en sus actividades:

  • Encuentros
  • Charlas
  • Talleres

Luego vimos la presentación de Nacho Peña de Globant que con su estilo tan particular e histriónico compartió su experiencia en aplicaciones con un ciclo de vida hiper explosivo Nos conto como las decisiones de arquitectura se sopesan con los tiempos requeridos por la dinámica de este tipo de aplicaciones. Vimos como obviamente se puede acelerar ese ciclo a partir de tomar riesgos, y como la disponibilidad de recursos y la posibilidad de realizar inversiones de riesgo compensan la vuelta atrás de esas decisiones. Fue una charla muy entretenida y nos dió una mirada super práctica.

Finalmente presentó su caso Diego García de Lateral View.  “Funciones Lambda: el futuro ya llegó”. Más que interesante, mientras recorría su proyecto fue compartiendo las decisiones de arquitectura que tomó en cada etapa, aciertos errores pero lo más interesante fue lo innovador de su solución y el debate que despertó en conceptos que hoy se discuten mucho, serveless, microservicios, SAAS vs PAAS… otro debate que da para un meetup dedicado.

Les dejo la presentación de Diego y el link a su proyecto

Funciones Lambda- el futuro ya llegó

https://github.com/diego1686/newsletter-subscription

Espero que sea de utilidad y no duden en comentar o compartir sus opiniones y/o dudas.

Un placer haber participado en la organización del evento, nos vemos en el próximo meetup de ArqConfMDQ!!!

2018-06-18 at 2.09.38 PM (1).jpeg   07706a59-7dfb-4d68-8423-56a3e6eb6355.jpg535ba8ff-3285-4f3a-a5a1-2e1763f432ea.jpg    da038ea4-caee-4e2e-bb40-5bd39508514d.jpg2018-06-18 at 2.09.37 PM.jpeg   20180614_180034.jpg

Advertisements

IT Architectural Meetup @ Buenos Aires

El pasado jueves tuve la suerte de participar de la primera reunión del grupo “Arquitectura IT ¿Cuales son las responsabilidades?”. Fue una gran experiencia y conocí muchas personas nuevas muy agradables.

Este grupo tiene por objetivo compartir experiencias de arquitectura desde muchos puntos de vista. Participaron tanto arquitectos de empresas de verticales bien definidas como telecomunicaciones, banca, y salud y también de empresas de servicios de IT. Esto promovió un ambiente ideal para el intercambio de ideas y perspectivas.

La reunión se llevó a cabo en las oficinas de FluxIT en Puerto Madero, instalaciones muy cómodas y modernas. Que nos permitió llevar adelante debates abiertos así como actividades en grupos reducidos.

Este primer encuentro giró en torno a los bloques de construcción de una arquitectura, Activos, Lineamientos y Servicios. La dinámica fue separarse en grupos uno por cada uno de estos elementos y luego en charla abierta exponer las ideas condensadas. Muy interesante!!!.

En particular participé del grupo de Activos, allí empezamos a esbozar ideas de que era un activo, y sobre todo si ese activo era de arquitectura.

¿Quién es dueño de un activo?

Quién dirige su ciclo de vida, quién lo opera y mantiene, quién lo implementa.

Entre los activos sin duda encontramos todos los documentos generados:

  • Lineamientos
  • Procesos
  • Assessment
  • Catálogos
  • Blue prints

pero también llegamos a la conclusión que son las piezas de software que responden a los requerimientos no funcionales de la arquitectura.

activos

Creo que apoyamos esta última idea más que nada porque encontramos una muy pintoresca fórmula matemática que la representa.

Respecto a este tema tuvimos varias discusiones, ¿debe arquitectura implementar estos activos?, pues depende, depende del grado de madurez del área de arquitectura, de la empresa e incluso de la fortaleza y respaldo con que cuente el área. Si el área es nueva quizás es algo bueno que para lograr presencia se adueñe de estos activos y hasta que se genere un gobierno maduro se apropie de la operación para lograr presencia en los procesos de desarrollo, integración e implementación. A medida que madura iremos logrando mantener esa presencia separandonos de la operatoria. Sin duda es una estrategia y cada cultura empresarial será más o menos propicia a este modelo.

“Todos queremos una arquitectura con los pies en el barro.”

Esta idea fue el eje de las discusión. Todos los que integramos el grupo éramos amantes del código y ninguno reniega de ese primer amor. Fuimos muy críticos de una arquitectura de papel e idílica, sin una fuerte dosis de realidad. Esto fue un factor de peso en las conclusiones del grupo de trabajo.

Los otros grupos tuvieron presentaciones muy buenas, sin poder precisar los ejes de sus discusiones paso a contar algunas de las ideas que compartieron:

lineamientos

Dar lineamientos sin duda es una de las grandes responsabilidades de un equipo de arquitectura. Pero aquí hicimos mucho hincapié en como dábamos esos lineamientos y que llegada lográbamos, así surgieron dos ideas muy importantes:

  • El arquitecto es un agente de venta que debe lograr un convencimiento de que aplicar estos lineamientos es conveniente. Debemos tratar de evitar la imposición.
  • Siempre debemos considerar contextos y circunstancias donde sea posible considerar excepciones a estos lineamientos.

servicios

Cuando giramos hacia los servicios no hicimos más que confirmar, resaltar y poner en negrita el rol de venta de un arquitecto y coincidimos que la comunicación es el eje fundamental del servicio que presta arquitectura. En el día a día muchos son los entregables que genera, ninguno de ellos tiene validez si luego no se capitaliza en los desarrollos y/o implementaciones de IT tanto en la misma empresa (Organización como vertical de negocio), como en una empresa a la cual le brindamos servicios.

Algunas conclusiones

Los servicios que brinda arquitectura produce activos que deben cumplir con los lineamientos que al mismo tiempo son activos que se utilizan para brindar servicios. Independientemente de este divertido juego de palabras esta sesión de filosofía tecnológica dejó algunas ideas interesantes:

  • Creemos firmemente que arquitectura debe gobernar los componentes responden a necesidades de la arquitectura misma.
  • Estos componentes son activos de arquitectura.
  • Los lineamientos deben promoverse no imponerse.
  • Siempre debemos dejar un espacio a las excepciones.
  • Todos los servicios de arquitectura se basan en la comunicación.
  • Todo servicio produce un nuevo activo.
Un interrogante que  quedó pendiente es ¿qué significa ser el dueño de un activo?. A partir de allí surge la premisa “arquitectura en la realidad y no el arquitectos filósofos”.
Lo más importante

Lo cierto es que más allá de la ciencia pase una tarde súper agradable, conocí gente de la cuál aprender y con la cual compartir. Me sentí valorado y en un ambiente de pura honestidad. Este grupo tiene futuro.

Siempre hay cosas para mejorar. De mi parte me gustaría que el grupo se volviera más variado en cuanto a las tecnologías de origen. Estaría bueno incorporar la visión de un arquitecto del mundo SAP o gente del área de infraestructura para nutrir con conceptos de arquitectura de hardware, etc.

El ambiente permitió el humor y nos permitimos jugar y divertirnos, y sobre todo rescato:

formula

De más está aclarar que todos los derechos de esta fórmula están reservados al grupo de discusión de activos del día del evento. 😛