¿qué requisitos de cumplir una arquitectura T.I.? ¿cuales deben ser sus objetivos?

No son preguntas fáciles de responder, sin embargo, en un principio siempre podemos tirar de la lista clásica de los requisitos no funcionales. Son estos:

  1. Escalabilidad
  2. Mantenibilidad
  3. Fiabilidad: integridad y consistencia
  4. Disponibilidad
  5. Extensibilidad
  6. Rendimiento
  7. Capacidad de monitorización
  8. Seguridad

En cuanto a otro tipo de requisitos, la arquitectura debe en lo posible ocultar los detalles técnicos de la tecnología empleada y permitir así reducir las habilidades necesarias por parte del equipo de desarrollo.

Debe también facilitar el desarrollo de las aplicaciones, haciendo posible un desarrollo rápido, con alta productividad, que acorte los tiempos en los que la aplicación puede salir al mercado (time to market).

También debe proporcionar otros servicios técnicos haciendo posible que el desarrollador se concentre en implementar la lógica de negocio y no ocuparse de aspectos como el control de concurrencia, de transaccionabilidad, trazas, control de errores que normalmente proporciona el servidor de amplicaciones (contenedor donde se ejecuta la aplicación) y el framework de arquitectura.

Si la arquitectura está orientada a servicios debe cumplir además otras características (ver las entradas en este mismo blog aquí y aquí).

Es evidente que una arquitectura software conlleva una serie de características y requisitos que hacen que su implementación no sea trivial en absoluto. Sin embargo, todos estos puntos a considerar que acabo de citar aqui los resumiría en únicamente tres que creo que comprenden todos los demás:

  1. Sencillez: debe seguir el principio K.I.S.S. Hay que hacer las cosas tan simples como se pueda. En ocasiones, podemos elegir entre varias opciones, y aunque parezca increíble, en un gran número de ellas elegimos la opción más complicada.Y es que las cosas complejas, raras, “extrañas” o simplemente “peregrinas” tienen un alto coste en mantenibilidad, extensibilidad, rendimiento, etc.
  2. Estándar: debe basarse en estándares. Una aplicación de negocio es lo suficientemente compleja ya como para ocuparse de aspectos que ya deben venir resueltos. No se puede reinventar la rueda cada vez. Por ejemplo, el acceso a datos desde Java ya está inventado, podemos usar JPA, Hibernate o Spring DAO. Para la seguridad, podemos usar seguridad declarativa J2EE.
    El uso de estándares además permite una mejor evolución ya que podemos usar productos de diferentes vendedores sin atarnos a ninguno de ellos. Por otra parte, siguiendo los estándares podremos encontrar en el mercado personas preparadas que conozcan una determinada tecnología. Evidentemente si usamos un tecnología propietaria, que puede estar incluso realizada en la propia empresa, no será muy difícil conseguir estos recursos fuera de la propia empresa.
    Esta característica incluye por tanto la mantenibilidad, fiabilidad, disponibilidad, monitorización, seguridad…
  3. Rapidez: una de las principales necesidades que plantea el área de negocio es que tiene que ser muy rápido poner un nuevo servicio o aplicación en la calle. Tan rápido como rápido cambia las condiciones de mercado y la competencia. En ocasiones no nos podemos permitir plazos de desarrollo de un año o más ya que nuestra empresa podría perder la ventaja competitiva.
    Con esta característica de rapidez, sin embargo, ocurre algo curioso y es que no suele llevarse bien con los estándares. Y es que cuanto más se usan los estándares de manera directa (sin un framework que te oculte los detalles técnicos) menos productivad se obtiene (esto se puede mitigar con el uso herramientas de desarrollo o generadores de código)

En mi opinión, éste debe ser el verdadero “SER” de la Arquitectura: Sencillez – Estándar – Rapidez

Comparte este artículo…