Arquitectura

¿Qué es un arquitecto de software?

Para mí, un arquitecto de software es un gran apasionado y entusista por crear y diseñar software de calidad que lleva muchos años desarrollando aplicaciones, componentes y servicios y cuyo lema principal es que la creación de aplicaciones empresariales es un arte y una ciencia a la vez.

Además, un arquitecto de software debe tener una serie de habilidades personales y técnicas para ser un lider y colaborador con el equipo de desarrollo, tomar decisiones de diseño, modular los sistemas de información, dominar lenguajes DSL, bases de datos, redes, comunicaciones, tecnologias, programación y por supuesto ser un buen comunicador y negociador con clientes, managers y equipos de operaciones.

Introducción

La arquitectura de software tiene muchas facetas que abarcan desde el análisis, diseño, desarrollo, documentación hasta la implementación y puesta en marcha del sistema de información sin olvidar todo lo demás, como las estructuras del software, testing, escalabilidad, disponiblidad, seguridad, rendimiento, etc. para lograr satisfacer las necesidades del cliente en el tiempo y entregar valor al negocio.

Una buena arquitectura y un buen diseño debe identificar y especificar los requisitos que afectan a la estructura de la aplicación de forma clara y debe ser lo suficientemente flexible para manejar la deriva natural que se producirá con el tiempo en hardware y software, así como posibles cambios de escenarios y futuras necesidades de los usuarios.

A la hora de pensar una arquitectura, influyen muchos factores y nunca debemos perder de vista estos que son fundamentales:

  • Application Architecture (clases, componentes, modulos, relaciones, etc)
  • System Architecture (n-tiers, servers, subsistemas, servicios, DBs, etc)
  • Software Architecture (para mi la combinacion de 2 anteriores)
  • Enterprise Architecture (estrategias empresariales que debemos cumplir)
  • Cross-Cutting (audit, logs, excep, integration, security, etc.)
  • Quality Assurance (garantizar calidad de todo el sistema información, R-E-D)

La meta de toda arquitectura, entre otros aspectos, es ofrecer servicios al negocio, a otras aplicaciones de la organizacion y proveedores externos. El objetivo final es construir nuestra API de servicios de negocio lo más robusta y sencilla de consumir.

Siempre que pensamos en arquitectura hay que diferenciar entre Object Oriented Programming y Network Programming  y nunca olvidar este punto: Fallacies of distributed computing (Wikipedia) sobretodo hoy en dia, donde cada vez más usuarios usan dispositivios móviles para conectarse y consumir información de nuestro backend.

Por ultimo, siempre tener presente este articulo muy recomendable para valorar los efectos negativos de nuestras decisiones: Arquitectura de software y mal diseño = perdida de dinero

Microsoft Architecture Overview

Como guía de consulta, aunque sea del año 2002, es totalmente válida para enteder todos los aspectos que abarcan una arquitectura y siempre recomiendo tenerla a mano para consultar información sobre:

Atributos Transversales (cross-cutting)

Principales beneficios de una arquitectura

Adaptabilidad: Añadir características técnicas al sistema o nuevas de reglas de negocio son más fáciles de lograr, ya que una arquitectura de software debe tener una clara separación de responsabilidades entre sus componentes y módulos.

Agnóstica:  Estar por encima de las modas o tendencias de la industria y no depender de tecnologías concretas para aplicar cambios en el futuro en caso de ser necesario.

Mantenibilidad: Es más fácil mantener el software existente, ya que la estructura del código es visible y conocido, por lo que es más fácil de encontrar errores y anomalías.

Productividad: Agregar nuevas características al software existente debe ser fácil, ya que la estructura ya está definida y la ubicación de todas las piezas del sistema se conoce de antemano.

Testing y diferentes “logicas” en nuestras aplicaciones

Normalmente, cuando hablamos de testing y que lógica vamos a probar en nuestras aplicaciones lo relacionamos siempre con “Logica de Negocio” cuando en realidad, en nuestras aplicaciones escribimos muchos tipos de lógica diferentes, es muy importante a la hora de valorar el testing, definir el equipo de testers, el esfuerzo en diseñar todas las pruebas,  el tiempo y coste de las mismas porque impactará directamente en el proyecto.

  • Lógica de Negocio
  • Lógica de Presentación
  • Lógica de Interacción de usuario
  • Lógica de Transformación de datos
  • Lógica de Database (Stored, Functions, etc.)
  • Lógica de Integración entre sistemas/componentes
  • Ejemplo: app. web (no funciona igual en todos los navegadores)
  • Ejemplo: app. móvil android5 (ok),  android6 (no funciona – temas de permisos)

Nota: Es un concepto clave para tenerlo en cuenta en futuras aplicaciones hasta donde queremos llegar con nuestras pruebas, por ello, siempre recomiendo crear un documento de Plan de Pruebas para acordar con el cliente hasta donde llegar, porque como dice ISTQB, es imposible probarlo todo.

Cuestiones clave para debatir

  • ¿Porque no responden las aplicaciones a la velocidad que avanza el negocio?
  • ¿Porque no se hace testing de todas las aplicaciones y módulos?
  • ¿Porque nos lleva mucho tiempo reaccionar a los cambios del negocio y tecnologia?
  • ¿Porque nos cuesta tanto trabajo y dinero interconectar aplicaciones?
  • ¿Porque tenemos codigo repetido y duplicado en varios apps de software?
  • ¿Que tienen en común Gmail, Facebook, Twitter, Whatsapp, Pinterest, Instagram…?

Todas coinciden en algo: Una buena arquitectura con un backend super potente que provee de servicios y datos a millones de clientes de multiples plataformas, Android, iOS, Windows y Web.