¿Qué es un arquitecto de software?
Para mí, un arquitecto de software es un gran apasionado y entusiasta 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 líder 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, tecnologías, programación y por supuesto ser un buen comunicador y negociador con clientes, managers y equipos de operaciones.
Como recordatorio, una frase que siempre tengo presente cuando se habla de decisiones sobre arquitectura de aplicaciones y que sin duda la experimentamos en nuestro día a día: «Disagreeing on architectural decisions is a normal and healthy part of software development.«
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, disponibilidad, 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 organización y proveedores externos. El objetivo final es construir nuestra API de servicios de negocio lo más robusta y sencilla de consumir.
Cuando pensamos en la arquitectura, hay que diferenciar entre Object Oriented Programming, Network Programming y tener en cuenta Fallacies of distributed computing (Wikipedia) sobretodo hoy en día, donde cada vez más usuarios usan dispositivios móviles para conectarse y consumir información de nuestro backend.
- The network is reliable.
- Latency is zero.
- Bandwidth is infinite.
- The network is secure.
- Topology doesn’t change.
- There is one administrator.
- Transport cost is zero.
- The network is homogeneous.
Por último, siempre tengo presente este articulo, muy recomendable, para valorar los efectos negativos de una mala arquitectura o la ausencia de un arquitecto en los proyectos: Arquitectura de software y mal diseño = perdida de dinero
Funciones de un arquitecto de software
Las tareas más comunes donde un arquitecto participa se pueden englobar «a groso modo» en las fases de los proyectos de software que todos conocemos.
- Inicio: definición y alcance del proyecto
- Analisis: análisis funcional y requerimientos
- Diseño: diseños preliminares, prototipos, detalladado, especificaciones
- Codificación: programación y debug
- Validación: realizar tests y pruebas del sistema
- Instalación: puesta en marcha del sistema.
- Explotación: seguimiento y diagnósticos del sistema en producción
A parte realiza muchas otras funciones en su día a día:
Arquitectura: Definición de arquitectura de las aplicaciones, diagramas, vista física, vista lógica, patrones y principios de arquitectura, etc.
Selección de Software: Pilas de aplicaciones, bases de datos, librerías, frameworks, estándares tecnológicos, etc.
Selección de Infraestructura: Sistemas Operativos, hardware, redes, failover, sistemas de recuperación, etc.
Requisitos no Funcionales: Rendimiento, escalabilidad, seguridad, etc.
Liderazgo Técnico: responsabilidad y autoridad, dirección de equipos, etc.
Coaching y Mentoring: Ayuda sobre problemas técnicos, ofrecer alternativas, etc.
Metodología de Proyectos: Waterfall, Scrum, Iterativo, ITIL, ISTQB, RUP, XP…
Procesos de Desarrollo: Control de versiones, procesos de construcción, integración continua, automatización de pruebas y otras herramientas de desarrollo.
Prácticas y Estándares: Guías y estándares de codificación, libros blancos, selección de herramientas, codigos éticos, buenas prácticas, etc.
Diseño, Desarrollo y Pruebas: Diagramas UML, codificación, pruebas unitarias, etc.
Experiencia: Conocimiento sobre tecnologías y estar al día en cuanto a tendencias en arquitecturas, nuevos retos tecnológicos, transformación digital, cloud, contenedores, etc.
¿Qué es una aplicación empresarial?
Uno de los objetivos más importantes de la arquitectura es diseñar y construir aplicaciones empresariales, básicamente, 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)
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:
- Microsoft Architecture Overview
- Enterprise Architecture
- Application and Technology Architecture
- Conceptual, Logical, and Physical Views
- Application Architecture
- Application Patterns
- Technology Architecture
- Technology Patterns
Arquitectura y monolitos
No todos los monolitos son candidatos perfectos para la refactorización a microservicios, mientras que algunos ni siquiera «sobreviven» a esa fase de modernización.
Al decidir si un monolito es un posible candidato para la refactorización, hay muchos posibles problemas a considerar porque el camino de refactorización de un monolito a microservicios no es sencillo y sin desafíos
Una aplicación heredada mal diseñada debe ser rediseñada y reconstruida desde cero siguiendo patrones arquitectónicos modernos para microservicios e incluso contenedores. Las aplicaciones estrechamente vinculadas con los almacenes de datos también son malos candidatos para la refactorización.
Arquitectura y microservicios
La arquitectura basada en microservicios está alineada con los principios de arquitectura orientada a eventos y arquitectura orientada a servicios (SOA), donde las aplicaciones complejas se componen de pequeños procesos independientes que se comunican entre sí a través de API a través de una red. Las API permiten el acceso por otros servicios internos de la misma aplicación o servicios y aplicaciones externos de terceros.
Cada microservicio se desarrolla y escribe en un lenguaje de programación moderno, seleccionado para ser el más adecuado para el tipo de servicio y su función comercial. Esto ofrece una gran flexibilidad al combinar microservicios con hardware específico cuando sea necesario, lo que permite implementaciones en hardware de bajo costo.
Aunque la naturaleza distribuida de los microservicios agrega complejidad a la arquitectura, uno de los mayores beneficios de los microservicios es la escalabilidad. Con la aplicación general volviéndose modular, cada microservicio se puede escalar individualmente, ya sea manualmente o automatizado a través de escalado automático basado en la demanda.
Centro de Arquitectura de Azure
Aunque no hay una solución única para diseñar una arquitectura, hay algunos principios universales que se aplicarán con independencia de la arquitectura, tecnología o proveedor en la nube.
En la web de Microsoft disponemos del Centro de arquitectura de Azure con mucho material de estudio, guías, arquitecturas de referencia para todo tipo de soluciones.
Una arquitectura excelente comienza con una base sólida que se basa en estos pilares:
- Seguridad
- Rendimiento
- Escalabilidad
- Disponibilidad y capacidad de recuperación
- Eficiencia y operaciones
En una arquitectura ideal, se crearía el entorno más seguro, de mayor rendimiento, de alta disponibilidad y el más eficaz posible. Sin embargo, al igual que con todo, hay ventajas e inconvenientes.
Crear un entorno con el nivel más alto en todos estos aspectos tiene un costo. Ese costo puede venir en forma de dinero real, de tiempo necesario para entregar o de agilidad operativa. Cada organización tiene diferentes prioridades, lo cual afectará a las opciones de diseño que adopten para cada uno de estos aspectos. Al diseñar la arquitectura, deberá determinar qué ventajas y desventajas son aceptables y cuáles no.
Seguridad ante todo
El uso de un enfoque multicapa de seguridad aumentará la seguridad. Normalmente se conoce como defensa en profundidad y las capas se desglosan como sigue:
- Datos
- Aplicaciones
- Máquina virtual/proceso
- Redes
- Perímetro
- Directivas y acceso
- Seguridad física
Cada capa se centra en las distintas áreas donde pueden ocurrir ataques y se crea una protección profunda en caso de que se produzca un error en una capa o de que un atacante la traspase.
Abordar la seguridad por capas aumenta el trabajo que un atacante debe hacer para obtener acceso a los sistemas y los datos. En cada capa se aplicarán diferentes controles de seguridad, tecnologías y funcionalidades. A la hora de identificar las medidas de protección que se implantarán, los costos suelen ser motivo de preocupación y es necesario equilibrarlos con los requisitos empresariales y el riesgo total para la empresa.
No existe un solo sistema de seguridad, control o tecnología que pueda proteger completamente su arquitectura. La seguridad es algo más que tecnología, incluye también las personas y los procesos.
Importancia de la eficiencia y las operaciones
La eficiencia se centra en identificar y eliminar el desperdicio que normalmente se produce al aprovisionar más capacidad de la necesaria. Existen también ciertos costos operativos. Estos costos operativos se muestran como pérdida de tiempo y más errores.
El desperdicio puede manifestarse de varias maneras:
- Una máquina virtual que tiene siempre un 90 % de inactividad
- Pagar por una licencia incluida en una máquina virtual cuando ya se es propietario de una licencia
- Conservar datos con acceso infrecuente en un medio de almacenamiento optimizado para el acceso frecuente
- Repetir manualmente la compilación de un entorno que no sea de producción
En cada uno de estos casos, se invierte más dinero del que se debe, y cada uno presenta una oportunidad para reducir los costos.
Funcionalmente, es importante contar con una sólida estrategia de supervisión.
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.
Aplicaciones Ejemplos
Aquí dejo una lista de aplicaciones publicadas por Microsoft para analizar y estudiar como están diseñadas y construidas:
1. Visitors application
2. Expenses application
3. Staff application
4. Travel application
5. Vacation application
6. Face recognition app
Project MyCompany Suite: http://aka.ms/mycompanyapps
MyShuttle.biz with Azure and Visual Studio 2015
En esta aplicación se presento en el evento Microsoft Connect() basada en Azure backend services y con integracion de Office 365 usando tecnologias de Microsoft Azure.
eShopOnContainers – Docker & Microservices
En esta aplicación de ejemplo para Visual Studio 2017 podemos consultar y probar una aplicacion diseñada con .NET Core usando microservicios y contenedores para tener una visión de como se puede implementar este tipo de soluciones usando tecnologias de Microsoft y Azure.
Project eShop: https://github.com/dotnet-architecture/eShopOnContainers
Bueno, espero que este articulo sea de utilidad y ayude a entender un poco más a la gente el concepto de Arquitecto de Software y sus funciones como figura clave para el éxito en el desarrollo de las aplicaciones empresariales.
Santimacnet 