Los principios básicos de arquitectura TIC son los fundamentos que guían el diseño y la implementación de una arquitectura de TI. Estos principios se basan en la experiencia y el conocimiento de los arquitectos de TI, y se aplican a todos los aspectos de la arquitectura de TI, desde la infraestructura hasta las aplicaciones.

Algunos de los principios básicos de arquitectura TIC más importantes son los siguientes:

• Eficiencia: La arquitectura de TI debe ser eficiente en términos de recursos, costes y rendimiento.
• Sostenibilidad: La arquitectura de TI debe ser sostenible a largo plazo, tanto en términos ambientales como económicos.
• Flexibilidad: La arquitectura de TI debe ser flexible para adaptarse a los cambios en los requisitos y las tecnologías.
• Seguridad: La arquitectura de TI debe ser segura para proteger los datos y la información.
• Gobernabilidad: La arquitectura de TI debe estar bien gobernada para garantizar que se cumplan los objetivos empresariales.

Estos principios se pueden aplicar a cualquier contexto de arquitectura de TI, desde una pequeña empresa hasta una gran organización.

A continuación, se explica cómo aplicar estos principios al diseño de software, a la tecnología y al coste y mantenimiento de la solución:

1.Principios sobre diseño de software

1.1 Segregación de responsabilidades: Las aplicaciones deben estar divididas en bloques funcionales independientes, cómo procesos de negocio o servicios, con el fin de poder ofrecer sistemas con responsabilidades funcionales claras y ordenadas.

1.2 Arquitectura sostenible: El objetivo es que el sistema sea fácil de ampliar sin sufrir un gran impacto en el cambio. Esta meta se alcanza dividiendo el sistema en componentes y ordenando esos componentes en una jerarquía de dependencia que protege los componentes de más alto nivel de los cambios en los componentes de nivel bajo.

1.3 Arquitectura desacoplada: Se deben diseñar componentes y aplicaciones que sean completamente autónomos e independientes. Con el objetivo de cumplir los siguientes criterios:

Componentes autónomos que se desarrollan y se despliegan independientemente.

Componentes independientes, pueden ser reemplazados o actualizados sin afectar al resto de componentes.

1.4 Arquitectura orientada a la segregación de APIs: La mayoría de sistemas están compuestos por subsistemas que recogen pequeñas funcionalidades y que requiere que se comuniquen entre sí. Es por eso que cada sistema debe depender solo de lo que es necesario y en el diseño se debe aportar una separación clara de API que ofrezca esta condición.

1.5 Arquitectura orientada al uso de interfaces: Desde el diseño se debe aportar una guía de cómo interactúa la solución con ciertas herramientas o frameworks es por eso que las dependencias de alto nivel no deben depender de las de bajo nivel o las abstracciones no deben depender de los detalles.

2.Principios sobre tecnología

2.1 Arquitectura sostenible

Desde el área de tecnología de la información de Asepeyo, con el objetivo de promover un mantenimiento y evolución de aplicaciones sostenibles se fomenta una separación entre dos capas claras:

• • Capa orientada a servicios (backend): esta capa deberá exponer su negocio mediante la tecnología web REST y utilizar JSON como formato estándar de mensajería.
  • Capa de presentación (frontend): esta capa deberá estar construida con tecnología estáticas (Html5,javascript/css). También podrá intercambiar mensajería con la capa de servicios.

2.2 Software sostenible

Se debe garantizar que las diferentes piezas (productos, librerías …) que componen un sistema deben ser lo más estables posible. Para ello nuestros productos deben estar compuestos por versiones con la nomenclatura que el fabricante garantice como estable como Long-Term Support (LTS) o General Availability (GA).

Un sistema productivo no puede incorporar versiones no consolidadas (snapshot, alpha, release candidate…) de los componentes que formen parte.

2.3 Estándar en el intercambio de datos

El software y el hardware deben ajustarse a estándares definidos que promueven el intercambio de datos.

2.4 Política de entornos

Las aplicaciones deben cumplir con la política de entornos de Asepeyo que promueve unos entornos pre productivos sostenibles.

Cabe destacar que las pruebas hechas a preproducción tengan validez, es necesario que los entornos de preproducción y producción sean idénticos en cuanto al diseño, aunque los recursos asignados a preproducción sean inferiores.

3. Principios sobre coste y mantenimiento de la solución

3.1 Costes sostenibles

Desde el área de arquitectura de sistemas de Asepeyo se promueven las siguientes prácticas para gestionar correctamente los costes relacionados con infraestructura:

• • Monitorizar los servicios para identificar necesidades de ampliación o reducción de recursos y poder ajustar los costes en consecuencia.
  • Diseñar la arquitectura con una planificación de las cargas de trabajo óptima en costes, de forma que se equilibren cuando sea posible las ventanas de ejecución de los componentes (online, extracciones, analítica, procesos batch …), por evitar los picos de carga y que se reparta de forma balanceada según las necesidades del negocio.
  • Arquitectura mínima. Hay que tener en cuenta la escalabilidad y hacer una previsión (mínimo 1 año) con el objetivo de conseguir una arquitectura sostenible en el tiempo.

3.2 Beneficio máximo al menor coste y riesgo posible

Hay que tener presentes los costes de infraestructura y el modelo de licenciamiento requeridos para poner en marcha una solución, ya que representan un coste recurrente. A la hora de concebir una solución se debe identificar qué tipo de licenciamiento será el mejor para la solución deseada. Cuando se escoge un producto (opensource o comercial) o se elige hacer un desarrollo a medida, hay que hacer una evaluación del coste vs. beneficio de la opción elegida respecto a las otras:

• • Para necesidades comunes, utilizar «Opensource».
  • Para necesidades poco comunes, comprar.
  • Para necesidades únicos, desarrollar a medida.

3.3 Impacto de actualización

Pensar en el impacto de actualización que pueda tener un cambio de sistema operativo, middleware o producto allí donde se ejecuta la aplicación: cuanto menos acoplamiento con el sistema de base y más utilización de estándares existe , más sencilla será la actualización o la ampliación de funcionalidades de la aplicación.