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

¿Qué es una aplicación empresarial?

Uno de los objetivos más importantes de la arquitectura es diseñar y construir aplicaciones empresariales, basicamente, una aplicación empresarial es aquella destinada a resolver las necesidades internas de una empresa u organización, vamos a ver que significa este término, según la wikipedia:

Por software empresarial se entiende generalmente cualquier tipo de software que está orientado a ayudar a una empresa o a una organización a mejorar su productividad y/o a medirla.

El término engloba una amplia variedad de aplicaciones informáticas que incluyen desde programas de contabilidad y de ofimática, hasta sistemas de planificación de recursos empresariales (ERP), pasando por programas de gestión de clientes (CRM) y de recursos humanos, así como programas de cadena de suministros (SCM), etc.

Pero como vemos, sigue siendo una definición poco detallada, creo que la mejor definición la encontramos en palabras de Martin Fowler, cuando dice:

A grandes rasgos, una aplicación empresarial debe cumplir estas características:

  • Tener una interfaz de pantallas con las que el usuario final puede interactuar
  • Adaptada a los procesos y reglas de negocio de la empresa
  • Acceder a la información de forma concurrente
  • Manejar sistema de persistencia de datos
  • Control de acceso al sistema: usuarios y roles
  • Control de acceso a la información: quien puede crear, modificar o ver datos
  • Permitir mostrar y manipular los datos en diferentes modos
  • Posibilidad de integración con otras aplicaciones empresariales
  • A veces, deben procesar gran cantidad de datos en lotes (batch processing)
En resumen, todos sabemos lo que son y las conocemos como aplicaciones de seguros, facturación, contabilidad, tiendas online, CRM, ERP,etc.

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.

A %d blogueros les gusta esto: