Illustration by Marie Bergeron
Illustration by Marie Bergeron

Si bien es cierto, en la mayoría de las ocaciones las empresas se «casan» con una arquitectura en la cual ya tienen experiencias y les ha dado resultado, muchas veces después de tantos fracasos, sin considerar otros factores que determinen la o las arquitecturas correctas para un nuevo proyecto de software.

MIEDO, este es la primer limitante cuando escuchamos sobre una nueva tecnología, un nuevo desarrollo o una nueva arquitectura. Y es como comento anteriormente los desarrollos de software suelen ser un dolor de cabeza, ya que en mi experiencia del lado cliente, y platicando ahora con mis clientes, el común denominador en los desarrollos de software es miedo.

Miedo a volver a las jornadas que terminan hasta altas horas de la noche o incluso en las madrugadas, Miedo de que nuestro personal se vea frustrado y en cada liberación «algo» funcione mal, Miedo a Seguir pagando a multiples empresas y no conseguir lo que queremos. Miedo a que al final del camino nos demos cuenta que no tenemos el software que queríamos, que no tiene todas las funcionalidades que necesitamos, pero al menos hace lo básico.

Bueno hoy no vengo hablarles del MIEDO, sino vengo AYUDARLES de forma gratuita con esta información que va dirigida principalmente a lideres de proyectos, arquitectos, jefes de departamentos, etc.

Es importante mencionar que en ocaciones somos nosotros mismos en nuestro rol de cliente, lider o arquitecto quienes cometemos los errores a la hora de determinar cual es la arquitectura correcta para nuestro proyecto.

Y es que si bien es cierto necesitamos tener en cuenta las habilidades y conocimientos de nuestro equipo, no por ello tenemos que elegir una misma arquitectura para todos los proyectos. Es por eso que antes de elegir es importante el ANALISIS del problema, requerimientos y tener en cuenta distintos aspectos, a continuación te muestro los que considero primordiales.

1 Empecemos por lo abstracto antes de lo complejo.

Respira!!, antes de comenzar a pensar si la mejor opción es DO o AWS o Alibaba, y decidir que tu arquitectura estará en la nube, primero comienza con cosas más abstractas como «necesitamos una caja que procese pagos de forma asincrona» todo esto como nos sugiere UML en el diagrama de componentes.

Si tu comienzas diciendo usaremos MongoDB, NodeJS, etc. No es una buena opción.

2 Primero las vistas

Normalmente los arquitectos o lideres técnicos comienzan con patrones para «arrancarse», este pensamiento a parte de pobre resulta en la mayoría de las ocaciones en problemas.

Antes de decidir el patron de diseño yo te recomiendo que hagas un listado de las vistas que tendrá el sistema, no solo desde el punto de vista técnico sino funcional, normalmente esta información forma ya la tiene el area de requerimientos, si la consideras limitada, investiga y genera las vistas. Esto te ayudara en un futuro a determinar que usar en cada una de ellas. No todo se soluciona con un patron.

3 No esperes demasiado de tu primer borrador

Normalmente queremos que antes de analizar con nuestro equipo la solución propuesta tengamos hasta el IDE de desarrollo a usar.

Esto a veces resulta perjudicial porque nos cerramos a nuestro criterio sin tomar en cuenta la expertis de otros miembros de nuestro equipo como DBA, Desarrolladores, Tester.

Queremos controlar todo es por eso que tenemos en el mejor de los casos un machote de proyectos al cual recurrimos con un proyecto nuevo. Entonces vamos a tomar como nuestro primer borrador el diagrama de componentes en UML con anotaciones principales de las vistas, Sin Patrones, Sin Tecnologías, Solo con el conocimiento del problema.

4 Escucha todas las vistas

Cuando realizes la revisión en cada iteración antes de presentarla al cliente o responsables del proyecto, escucha a todos los miembros del equipo. Y no solo los escuches tu, pasen el tiempo que necesiten en la sala de juntas hasta que todos estén convencidos.

Si bien es cierto la responsabilidad caerá sobre el LT o Arq. Al involucrar a todo tu equipo y hacerlos parte de la solución. Tiene un doble proposito porque al estar convencidos ellos se comprometen de una forma mayor. Si ya se que los que me están leyendo son profesionales, pero en el fondo saben que esto es así, Cuando te sientes parte de la solución propuesta vas a luchar por que esta sea la mejor y no tenga complicaciones.

Finalizando

Existen mas puntos a considerar como clasificar los componentes por niveles de importancias, comunicación, cumplir los requerimientos no funcionales. Esto se los explico en otro post, si es de su interes.

Escriban a @abrahamstalin en todas las redes sociales.

Última modificación: 7 febrero, 2020

Autor