1er Encuentro de Arquitectura de Software en Mar del Plata

El día de ayer tuve la oportunidad de participar en el primer encuentro de Arquitectura de Software organizado por Aticma, Universidad FASTA, Universidad CAECE y Universidad Nacional de Mar del Plata.

Fue para mi un honor volver a mi alma mater y esta vez pararme del otro lado a compartir algo de conocimiento.  Agradezco a Fernando Soriano por la organización del evento y esta estupenda idea. Y a Santiago Blanco, Santiago Urrizola y Carlos Sallago por sumarse al panel de cierre y enriquecer la charla con su experiencia y conocimiento.

Comparto aquí la presentación que acompañó la charla. Esta presentación tuvo como eje central el impacto de la disciplina de arquitectura en el proceso de Ingeniería de Software. Mi intensión fue exponer como la arquitectura de software es un constante trade off que debe permitir a la empresa tomar decisiones de diseño conscientes y metódicas con el fin de lograr sus objetivos. Es menester del arquitecto nunca perder de vista estos objetivos.

La presentación recorre algunos conceptos de arquitectura, su contexto en base a la dimensión de la arquitectura objetivo y el modelo de empresa donde se lleva a cabo.

Una segunda parte abarca someramente técnicas y métodos que respaldan a la arquitectura de software como una disciplina.

Descargar “Presentación 1er encuentro de arquitectura mar del plata”

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. 😛