Arquitectura – Los pecados capitales del arquitecto Parte 1

Pecados capitales del arquitecto
Pecados capitales del arquitecto

Artículos relacionados

Introducción

¿Qué no debemos hacer para fracasar en un proyecto? Todo esto desde el punto de vista de la arquitectura. En esta primera parte hablare de esos detalles que muchas veces son dejados de lado y pueden ser catalogados como faltas graves dentro del proceso de arquitectura. Estos detalles a veces se dejan pasar por desconocimiento o simplemente no se quisieron tomar en cuenta. En este artículo veremos los primeros 13+0 puntos que se deben de tener en cuenta en las fases de requisitos, diseño y desarrollo. Muchos de los puntos que leerán a continuación son cosas que me han pasado, errores de los que se tienen que aprender a las buenas  o a las malas y el objetivo de este post es el de brindar este feedback para que no se vuelvan a repetir.

PECADOS CAPITALES DEL ARQUITECTO

A continuación se mencionaran los puntos que no deben dejarse de lado en el proceso de la arquitectura, unos puntos más graves que otros pero que de algún modo todos tienen un impacto sobre la arquitectura.

1. No conocer el giro del negocio del cliente

Como primer paso en todo proceso de arquitectura es básico conocer a que se dedica el cliente, cuál es su giro de negocio para saber qué tipo de soluciones se le puede ofrecer con la finalidad de ayudarlos a mejorar.

2. No conocer a los stakeholders

Si no conocemos a los stakeholders no sabremos a quienes está dirigido la solución, que tipo de personas serán afectadas o que restricciones puedan tener sobre el nuevo desarrollo, recuerden que ellos son los que toman las decisiones y están interesados en el sistema. Entre los stakeholders más comunes tenemos:

  • Usuarios finales
  • Gerente de proyectos
  • Equipo de desarrollo
  • Arquitecto
  • Operadores
  • Administrador de base de datos
  • Jefe del área
3. No conocer o no tener claros los requerimientos funcionales

Ningún requerimiento debe quedar ambiguo, todos deben estar bien definidos para conocer su alcance y estimar el tiempo de desarrollo. Si no tenemos este insumo claro no podremos identificar los requerimientos que impactan sobre la arquitectura o podemos dejar de lado alguno que si lo haga.

4. No asesorar técnicamente la fase de requerimientos

El papel aguanta todo eso lo sabemos muy bien, por tal motivo es importante que el arquitecto ayude a aterrizar ciertos requerimientos jalados de los pelos que muchas veces los analistas se inventan y se convierten en una pesadilla para el equipo de desarrollo.

5. Tomar una decisión basada solo en la experiencia previa

Es importante tener en cuenta la experiencia que hemos adquirido, pero no debe ser el único input que debemos usar al momento de diseñar un sistema. Puede ser que hayas desarrollado un sistema de ventas, pero no significa que otro sistema de ventas será siempre igual, cada negocio tiene sus propias necesidades, reglas y restricciones que deben ser tomadas en cuenta.

6. No conocer las restricciones del lado del cliente

Al igual que no se puede diseñar un sistema teniendo en cuenta solo la experiencia, no se puede empezar a diseñar si no se conocen las restricciones que tiene el cliente. Estas restricciones se pueden clasificar en:

  • Seguridad
    • Mecanismos de autenticación y autorización usados.
    • Repositorio de credenciales (Active directory, base de datos, etc)
  • Infraestructura
    • Versión del Motor de base de datos
    • Versión del sistema operativo
    • Tipo de procesador: 32 o 64 bits. Esto también se aplica al modo de ejecución de los procesos si están en 32 o 64 bits no solo al sistema operativo
    • Versión de servidor web
    • Algún producto o servicio que se deba usar (Sharepoint, MongoDb, NServiceBus, etc)
    • Ambiente de producción (Balanceadores, web farms, clusters de base de datos)
  • Comunicación
    • Mecanismos de comunicación entre servidores (Web services, com+, rest, etc)
    • Restricciones de comunicación entre servidores, por ejemplo: el servidor web no puede llamar al servidor de base de datos, etc.
    • Servicios externos que se deben usar.
  •  Desarrollo
    • Lenguaje de programación y/o versiones de framework.
    • Estándares de desarrollo usados por el cliente
    • IDE’s de desarrollo
    • Componentes de terceros y/o licencias.
    • Metodología de desarrollo
  • Despliegue
    • Proceso de despliegue
    • A través de un instalador
    • Solo se pasan los archivos modificados
7. No conocer los atributos de calidad o no poder medirlos

Los atributos de calidad nos permiten medir y conocer si la arquitectura planteada cumple con los objetivos del cliente, como atributos de calidad tenemos: seguridad, rendimiento, disponibilidad, interperabilidad, testeabilidad, usabilidad, etc. Sin esta información no podemos saber que estrategias debemos aplicar para que el aplicativo cumpla con lo que el cliente necesita. El otro caso es que estos atributos no sean medibles o no estén bien definidos, por ejemplo tenemos esta sentencia: Establecer una configuración de hardware que permita contar con un sistema disponible en producción con un bajo nivel de interrupciones en el acceso de los usuarios. Este requerimiento es ambiguo y no es medible, para poder convertirlo en un atributo de calidad se debe conocer:

  • ¿En cuánto se debe disminuir el nivel de interrupciones?
  • ¿Cuál es el nivel de disponibilidad que debe tener el sistema?
  • ¿Cuál es el intervalo de tiempo en el que ocurren estas interrupciones?
  • ¿Cuál es el dispositivo de hardware al que aplica este requerimiento?
  • ¿Qué debe ocurrir ante un fallo?
8. Usar las vistas equivocadas para transmitir la arquitectura

Sino escogemos las vistas adecuadas para los stakeholders más importantes no lograremos transmitir adecuadamente la arquitectura planteada. Por ejemplo: para el equipo de desarrollo seria útil contar con una vista de componentes o clases, para un administrador de servidores es útil contar con una vista de despliegue, para un analista funcional le va a ser más practico ver un diagrama actividades, para el gerente de área le puede servir un diagrama que muestre el contexto de la solución, etc.

9. No hacer pruebas de concepto

Básico, antes de proponer algo se debe probar. Recuerden la frase Fail Fast, mientras más rápido falles más rápido podrás buscar otra solución y el impacto será menor. Imaginen que el diseño propuesto no fue el adecuado o que el framework o librería que decidiste usar no funciona como lo esperabas a puertas de entrar a la fase de desarrollo o peor aún en la fase de pruebas.

10. Elegir un solo estilo de arquitectura para todo el sistema

En el caso de sistemas grandes que se dividen por módulos no es una buena idea escoger un estilo de arquitectura que se aplique a toda la solución. Imaginen un módulo de mantenimientos (CRUD) desarrollado con el estilo DDD o un módulo complejo e importante para el negocio desarrollado en 3 capas. Es importante saber identificar las necesidades y la complejidad de cada módulo para escoger el estilo de arquitectura que mejor se adapte a los requerimientos sin llegar a caer en la sobre ingeniería.

11. Usar un estilo de arquitectura solo porque está de moda

Aunque no está de más mencionarlo no se debería escoger un estilo de arquitectura solo porque está de moda, parece interesante o se quiere experimentar. Todo estilo de arquitectura debe estar sustentado con las decisiones hechas a partir de los drivers de arquitectura.

12. No transmitir adecuadamente la arquitectura al equipo

Algo que no debería pasar nunca es que el equipo de desarrollo no conozca o no entienda la arquitectura propuesta. Sino verán nacer un frankstein.

13. Usar la tecnología incorrecta solo porque está de moda o te gusta más

Al igual que al momento de escoger un estilo de arquitectura, el usar un framework o librería sólo porque están de moda o es nueva no es una buena decisión. No hay problema en usar algo nuevo, siempre y cuando estas decisiones estén respaldas por unas pruebas de concepto.

Update: 17/04/2015

0. No asesorar técnicamente al comercial o la parte de preventa

El punto “0” más conocido como la etapa de anteproyecto o pre-venta donde empieza todo sistema, el arquitecto debe asesorar, acompañar, validar y definir el alcance de la solución desde el inicio para luego no encontrarnos con sorpresas que nuestros amigos comerciales, con tal de vender, puedan ofrecer al cliente.

Para más información les recomiendo que sigan esta conversación en LinkedInGrupo Arquitectos .net – Arquitectura – Los pecados capitales del arquitecto Parte 1

Conclusión:

Aunque estos 13+0 puntos no son considerados como una regla de oro creo que es importante tenerlos en cuenta ya que en cierto modo pueden afectar el diseño de la arquitectura y el éxito del proyecto. Entre los más críticos tenemos: no conocer los requerimientos funcionales, no transmitir adecuadamente la arquitectura, no contar con atributos de calidad, no seleccionar el estilo de arquitectura adecuado, etc. Finalmente dentro de nuestro proceso de arquitectura se deben realizar los pasos que se consideren más importantes.

Referencias:
Metal Tip:

Este artículo lo escribí escuchando un top 10 con lo mejor del Heavy Metal del 2014, les comparto el enlace.

Anuncios

Un comentario en “Arquitectura – Los pecados capitales del arquitecto Parte 1

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s