Definiciones Semana 1-6

Ing. José Antonio Guerrero Hinostroza | Arquitectura de Software Empresarial IS-602

Teoría
Arquitectura de Software Empresarial IS-602

Semana 1
1. Introducción al curso, presentación del silabo y acuerdos.
Semana 2
1. Etapas clasicas de la arquitectura de software
Análisis de requerimientos
Entender que se construirá, cubrir los requerimientos de negocios, de usuarios,
funcionales y no funcionales, dando como resultado una compresión muy clara a
resolver.

Diseño de la solución
Propuesta a nivel diseño de solución, se puede trabajar en conjunto con un analista para
plantear una posible solución, en modelo, documentación, la finalidad es un detalle de
solución.

Desarrollo y evaluación
La etapa en la que desarrollador se construye el Software, se debe contar con el set de
requerimientos necesarios.

Despliegue
La fase de operaciones, se requiere la infraestructura, roles de operación quienes se
asegurarán de llevar el producto a producción (a disponibilidad para el usuario final)

Mantenimiento y Evolución
Dependen nuevamente de regresar a las fases de desarrollo y despliegue, en esta etapa
se está atento a la detención de errores o mejoras simples, hasta llegar al producto final.

J.A.G.H Página 1
Teoría
Arquitectura de Software Empresarial IS-602

El proceso de desarrollo tradicional tiene etapas muy marcadas, que tienen entradas,
procesos y salidas que funcionan como entradas de la siguiente etapa.

Desarrollo de etapas:
Análisis de requerimientos: Todo nace de un disparador que nos crea la necesidad de
crear un artefacto o un sistema. Necesitamos entender cuál es el problema que
queremos resolver. Hay requerimientos de negocio, requerimientos funcionales,
requerimientos no funcionales. Al terminar esta etapa debemos tener una comprensión
bastante clara del problema que vamos a resolver.
Diseño de la solución: Análisis profundo de los problemas para trabajar en conjunto y
plantear posibles soluciones. El resultado de esto debe ser el detalle de la solución, a
través de requerimientos, modelado (UML), documentación. Resuelve preguntas tales
como:
¿Cómo va el usuario a utilizar la aplicación?
¿Como se va a implementar la aplicación en producción y como será esto
administrado?
¿Cuáles son los atributos requeridos por la aplicación? (rendimiento, seguridad,
concurrencia, internacionalización, configuración)
¿Cómo se puede diseñar la aplicación para que sea mantenible y flexible con el
paso del tiempo?
¿Cuáles son las tendencias a nivel de arquitectura que pueden afectar la
aplicación actualmente o una vez que ha sido implantada?
¿Cuáles son las partes fundamentales de la arquitectura que representan el
riesgo más grande si se hacen mal?
¿Cuáles son los principales supuestos y cómo van a ser probados?
¿Cuáles son las partes de la arquitectura que tienen más probabilidad de
cambiar?
¿Qué condiciones pueden llevar a que se tenga que refactorizar el diseño
realizado?

¿Por qué es esta la mejor opción de arquitectura?

J.A.G.H PÁGINA 2
Teoría
Arquitectura de Software Empresarial IS-602

¿Qué medidas estamos tomando para mitigar los riesgos?

Desarrollo y evolución: Implementación de la solución, para garantizar que lo que se
está construyendo es lo que se espera. Al finalizar esta etapa tendremos un artefacto de
software.
Es donde plasmamos en “código” las dos anteriores etapas, además de realizar
test a dicho código
Debemos tener claros cuales son los criterios de aceptación de la solución, ósea
cual es el set de requerimientos necesario para construir esta solución y como
hacemos para evaluarlos (TDD), el resultado de esta etapa es un artefacto de
software.
Despliegue: Aquí vamos a necesitar de infraestructura y de roles de operación para
poder poner el artefacto a disponibilidad.
Debemos implementar la solución (artefacto) que ya tenemos construida en
productivo, AWS, GCP, Heroku, github-pages, hosting, play store, etc
Mantenimiento y evolución: Desarrollo + despliegue + mantenimiento, en esta etapa
estamos atentos a posibles mejoras que se hacen al sistema. En esta etapa el software
se mantiene hasta que el software ya deja de ser necesario.

2. Problemas en el desarrollo de software

Problemas en el desarrollo tenemos dos:
Esenciales: que tienen que ver con el problema que vamos a solucionar diseño y
comprobación del concepto. Los dividimis en 4 partes:
• Complejidad
• conformidad
• tolerancia al cambio
• invisibilidad
Accidentales: detalles de implementacion y produccion, lengiajes, integraciones,
servers, frameworks etc. Los dividimos en tres partes:
• Lenguaje de alto nivel
• Multi-procesamiento
• entornos de programacion
J.A.G.H PÁGINA 3
Teoría
Arquitectura de Software Empresarial IS-602

Los problemas accidentales nos traen ganancias cuando los resolvemos, incluso algunos
son solucionables con al alguna libreria, api, etc. Lo verdaderamente importante es
resolver los problemas esenciales.
Como solucionar dificultades esenciales:
Lo complejo de un desarrollo es lo esencial y no lo accidental. No hay ninguna bala de
plata que solucione el problema esencial del desarrollo de software. Para ello nos dan 4
formas de resolver las dificultades esenciales:
• No desarrollar: siempre que podamos primero ver si el problema se puede
solucionar con un software ya existente, con algo de open source, servicios,
integraciones y soluciones pequeñas que solucionen parte del probela etc.
• Proptotypado rapido: son la evolución de las metodologías agiles, la idea es
obtener e fedback lo mas rapido posible de si estamos resolviendo el problema
correcto. Para eso hay que ir evolucionando en pasos muy pequeños y siempre
obteniendo feedback. EL FEEBACK ES LA HERRAMIENTA DE DESARROLLO MAS
IMPORTANTE DENTRO DEL DESARROLLO DE SOFTWARE MODERNO.
• Desarrollo evolutivo: esta relacionado al tipiado rapido, consta de ir
desarrollando en pasos pequeños e ir evolucionando en ese sentido.
• Grandes diseñadores: personas que tengan la capacidad de diseñar una
solucion simple y que resuleva el problema de la mejor forma y con la mejor
calidad.

3. Roles
Metodología tradicional
Experto del dominio: Experto en necesidades de los requerimientos
Analista: Persona responsable a definir el problema y buscar la solución
Sysadmin(administrador del sistema): Encargado de toda la operación del
sistema
Equipos de desarrollos: Desarrolladores encargados de asegurar la calidad del
producto, se dividen en muchas áreas, QA, Tester, Desarrolladores, Arquitectos.
Gestor de proyectos: Administrador general de todo el proceso de desarrollo

J.A.G.H PÁGINA 4
Teoría
Arquitectura de Software Empresarial IS-602

Metodología ágil
Partes interesadas/stakeholders: Terceros expertos en el área del producto.
Dueño del producto: El cliente que conoce su producto y sabe sus problemas, él
puede realizas las historias y determinar cuál sería el mejor camino para priorizar
por etapas soluciones.
DevOps: Conecta el desarrollo y las operaciones de infraestructura
Equipos de desarrollos: Desarrolladores encargados de asegurar la calidad del
producto, los equipos son autogestionados para realizar ellos mismo dichas
funciones.
Facilitador: Administrador general del producto, generalmente se encuentra muy
atento a los nuevos cambios del día al día ya que irá cambiando todo el tiempo.

Semana 3
1. ¿Qué es arquitectura de software?
La arquitectura de software modela elementos de software, sus propiedades
visibles, etc. Es considerada un conjunto de desiciones princicpales de diseño para
llegar a un resultado de calidad en el sistema. La arquitectura puede emerger de
un equipo autogestionado o de un arquitecto externo, y está claramente
influenciada según el marco de referencia en el que se trabaje.

Ejemplo de la arquitectura de twitter:

Inicialmente procesa el mensaje que se twitteará a través de una API que se
comunica con unos servicios separados que a su vez tienen diferentes funciones y
que están en Asyncronous path.

Amazon web services, orienta su aarquitectura al despliegue, disponibilidad, carga

y crecimiento de una aplicación. Mientras Flux, de React, habla en un alto nivel de
su arquitectura según un flujo monodireccional de los datos.

J.A.G.H PÁGINA 5
Teoría
Arquitectura de Software Empresarial IS-602

2. Ley de conway
“Las organizaciones que diseñan software están limitadas a producir diseños que
son copias de las estructuras de comunicación de estas organizaciones”
Osea que, una organización compleja y burocrática solo puede producir sistemas
complejos y burocráticos
La ley de Conway, explica que los diseño de software se dan de la misma manera
que se estructura la organización.
Es decir, Dos módulos o sistemas no pueden comunicarse entre si, a menos que
la comunicación de los lideres de ambos sistemas sea mutua.
Esto se refleja en la estructura de la interfaz diseñada.

3. Objetivos del arquitecto

El arquitecto tiene varias partes interesadas “stakeholders” el cual tiene que
conectar esto requerimientos de cada stakeholders con la implementación del
sistema.
Stakeholders involucrados con diferentes requerimientos:
• Cliente: Entrega a tiempo y que no rebase el presupuesto.
• Manager: Comunicación clara entre los equipos que participan en el
desarrollo del sistema
• Dev: Que el desarrollo llevado acabo sea fácil de implementar y
mantener
• Usuario: Disponibilidad del producto.
• QA: Fácil de probar.
El arquitecto de software debe gestionar los siguientes puntos para cada
Stakeholder:
• Encontrar los riegos más altas que afecten en el desarrollo del sistema
(Cliente)
• Modularización y flexibilidad del sistema que se está desarrollando
(Manager)
• Modularidad, mantenibilidad y capacidad de cambio del software (Dev)
• Desisdir estrategias para la disponibilidad del sistema (Usuario)

J.A.G.H PÁGINA 6
Teoría
Arquitectura de Software Empresarial IS-602

• Que el sistema pueda ser modularizado y cada una destas partes pueda
ser probado de forma fácil (QA).

La unión de estos requerimientos (funcionales / no funcionales) va a llevar al

arquitecto a tomar decisiones que impactan directamente en el desarrollo del
software.

4. Arquitectura y metodologías
Metodologías Tradicionales: El arquitecto diseña una solución basada en los
Requerimientos, Restricciones y Riesgos. De este diseño resulta un Modelo y una
Documentación respectiva a su Implementación. Durante esta etapa de Diseño no
hay Implementación de Software.

Metodologías ágiles: La Arquitectura emerge de un equipo autogestionado que

realiza el diseño de una solución como algo evolutivo momento a momento (sprint
a sprint) lo que da lugar a reevaluar las decisiones tomadas. A su vez no se adelanta
a tomar decisiones que pueden ser postergadas a menos que sea absolutamente
necesario. Durante cada sprint realiza una rápida implementación para poder
tener feedback a través de métricas y alertas, para luego mediante una
retrospectiva, reevaluar o no decisiones tomadas.
Otra cosa importante en el desarrollo ágil es la posibilidad de implementar
“esqueletos de la aplicación" (Tracer Bullet) que nos permiten testear todas las
capas de nuestra arquitectura y crear una columna vertebral a partir de la cual
luego hacer incrementos de funcionalidad.

Principal diferencia: El problema de la falta de feedback en las Metodologías

Tradicionales durante la etapa de diseño.

J.A.G.H PÁGINA 7
Teoría
Arquitectura de Software Empresarial IS-602

Semana 4
1. Entender el problema
La parte más importante de entender el problema es: separar la comprensión del
problema de la propuesta de solución, si no se entiende la diferencia entre estos
dos puntos se tiende a solucionar problemas inexistentes y a hacer
sobreingeniería.
Espacio del problema:
Detalla ¿qué es lo que se va a resolver? (y qué no se va a resolver) sin entrar en
detalles del “cómo” (análisis del problema).
El espacio del problema nos ayuda a entender que es lo que vamos a resolver y
exactamente como imaginamos como esto va agregar un valor a nuestros usuarios
sin entrar en detalle de cómo lo va a resolver el sistema.
• Idea: ¿Qué queremos resolver?
• Criterios de éxito: ¿Cómo identificamos si estamos resolviendo el
problema?
• Historias de usuario: Supuestos de historias de lo que va a ganar el usuario
al utilizar la solución usando las características del problema a resolver.
Espacio de la solución:
Brinda el detalle del ¿“cómo” se va a resolver?, reflejando los detalles del
problema detectado y evitando resolver problemas que no se quiere o necesita
resolver (detalles técnicos).
Se refleja en el espacio del problema y trata de resolverlo teniendo en cuenta
todos los detalles técnicos necesarios.
Consta de:
Diseño: todo lo referente a la planificación del software, desde diseño UI, UX hasta
diseño de sistemas
Desarrollo: escribir el código, configuraciones y contrataciones de servicios
Evaluación: medir la eficiencia y eficacia del software frente al problema
Criterios de aceptación: medir el impacto del software, no importa lo bueno que
sea el problema si los usuarios no lo usan o no le ven uso

J.A.G.H PÁGINA 8
Teoría
Arquitectura de Software Empresarial IS-602

Despliegue (deploy): lanzar el software en ambientes productivos (mercado) y

empezar a mejorar las características con un feedback loop (crear, medir,
aprender).

2. Requerimientos
Los dividimos en 2 grandes grupos: requerimientos del producto (los que vienen
fijados por las partes interesadas) y los requeremientos de proyecto (fechas de
entregas, planes, disponibilidad de recursos humanos, etc).

Requerimiento de producto:
Los separamos en tres capas: negocio, usuario y funcional
Negocio: reglas de negocios alimentadas por los requerimientos del mismo.
Ejemplo si quiero conectar a personas que venden con personas que compran en
un proyecto de market_place, el sistema deberia tener la posibilidad de que los
usuarios puedan subir artículos.
Usuario: tiene que ver con las funcionalidades que va a requerir el usuario del
sistema. Siguiendo con el ejemplo del Market-place
sería que el usuario tuviera un panel de control y pueda autogestionarse la cuenta.
Funcional: ¿qué cosas tienen que pasar operativamente? Ejempo que el sistema
pueda cobrar a una tarjeta de credito luego de concretar una venta.
Requerimientos significativos para la arquitectura:
Agrupan cualquier tipo de requerimiento que afecten a la hora de diseñar la
arquitectura correcta.

Requerimiento de proyecto:
Recursos – Capacitación – Certificaciones – Documentación de usuario –
Infraestructura – Licencias – Plan de despliegue – Plan de transición – Acuerdos de
servicio

J.A.G.H PÁGINA 9
Teoría
Arquitectura de Software Empresarial IS-602

3. Riesgos
Describir el riesgo
Usar escenarios de fracaso que sean medibles y accionables.
Ejemplo:
“En situaciones de carga pico, los clientes experimentan latencias mayores a
cinco segundos.”
“Un atacante podría obtener información confidencial a través de un Ataque de
intermediario (Man in the Middle).”

¿Cómo identificamos riesgos?

Requerimientos (Dificultad / Complejidad)
Es importante conocer si el requerimiento es complejo, es decir si la dificultad de
resolver este requerimiento es muy alta.
Atributos de calidad (Incertidumbre)
Es importante entender si sabemos o no sabemos cómo mejorar un atributo
específico. Cuanta más incertidumbre hay en algo que detectamos que es
importante, más alto es el riesgo de esa situación.
Conocimiento del dominio (Riesgo prototípico)
Es importante saber si lo que hemos implementado ya ha sido implementado o
no, porque los dominios conocidos suelen tener riesgos prototípicos.
Priorizar riesgos
Es importante porque generalmente no podemos resolver todos, entonces si nos
concentramos en resolver riesgos que no eran importantes, entonces estaremos
invirtiendo mucho tiempo en algo que no era tan relevante. Debemos siempre
tener en cuenta qué riesgos ponen en peligro el éxito o fracaso de la solución.
Priorizamos nuestros riesgos y entendemos tanto nosotros como nuestros
stakeholders que algunos riesgos no vamos a poder cubrirlos en el primer
momento, sino que vamos a postergar el ataque o la mitigación de dichos riesgos
para cuándo podamos invertir tiempo en ellos. Así los riesgos y los requerimientos
van a ser priorizados y van a poder ser parte de nuestro plan organizado en dónde
entendemos qué es lo más importante arquitectónicamente para resolver.

J.A.G.H PÁGINA 10
Teoría
Arquitectura de Software Empresarial IS-602

4. Restricciones
“Una restricción limita las opciones de diseño o de implementación disponibles al
desarrollador.”
Partes interesadas (Stakeholders)
Limitaciones quizás que tengan que ver con su ecosistema o contexto de negocio,
limitaciones de tipo de regulaciones o cuestiones legales.
Integraciones con otros sistemas
Si vamos a comunicarnos con un sistema por HTTP necesitamos tener internet,
eso nos va a limitar en el ciclo de despliegue, como ejemplo.
Ciclo de vida del producto
Un ejemplo común es que a medida que evoluciona la aplicación el modelo de
datos es más difícil de cambiar

Semana 5
1. Panorama arquitectonico
Hay muchas librerías, muchos frameworks y conocimiento arquitectónico
implícito en las comunidades. Por ejemplo, si hablamos de palabras como MVC o
FLUX (con React) estamos hablando de arquitectura, sin embargo, esta implícito
dentro del uso de una tecnología específica, y de repente si hablamos de FLUX
estando en Java o C# no tiene ningún sentido, ya que no es una arquitectura que
se suele encontrar en esa tecnología, sin embargo arquitectónicamente tiene el
mismo valor y podría ser implementado en otra tecnología. Asi también, hay
decisiones arquitectónicas tales como si empezar un proyecto con un monolito o
iniciarlo con una estructura de microservicio, que se dan por sentado que
cualquier cosa seria de mucho mas valor iniciarlo como un microservicio ¿Por qué?
Puede ser porque es la tendencia, porque es lo que se da más fácil para el equipo
de desarrollo o porque las herramientas mas modernas de hoy están orientados a
microservicios, sin embargo, falta un análisis más profundo de que es lo que define
ese estilo o patrón de arquitectura y cuáles son los payloads o sacrificios que

J.A.G.H PÁGINA 11
Teoría
Arquitectura de Software Empresarial IS-602

estamos pagando por usarlos y cuáles son los beneficios que esperamos que
traigan.
Ningún patrón tiene solo beneficios, cuando hablábamos de que no hay balas de
plata, recordemos que ninguno de estos patrones ni estilos nos va a solucionar
todos los softwares, siempre hay beneficios y consecuencias de las decisiones de
diseño que tomamos.

¿Qué es un estilo de arquitectura de software?

Al hablar de un estilo de arquitectura hablamos de algo genérico. Por ejemplo,
podríamos entrar en detalles sobre diferentes páginas de internet: facebook,
twitter, wordpress, Wikipedia, etc. todas esas paginas de internet implementan
diferentes arquitecturas. Sin embargo, todas esas paginas son una pagina web, por
lo tanto tienen una arquitectura cliente-servidor donde hay un navegador web
que a través de un sistema de DNS y TCP/IP logra conseguir un documento en
formato HTML que se lo muestra a través de un navegador al cliente. Esa
estructura genérica define el estilo de una arquitectura, en donde, el estilo no nos
va a hablar en detalles que problema esta resolviendo del dominio del problema,
sino de que problema esta resolviendo arquitectónicamente a nivel de los
conectores entre diferentes aplicaciones. Como dijimos recién podrían ser por
ejemplo un navegador web y servidor, o podría ser una red de peer-to-peer, dos
sistemas que están intentando intercomunicarse, o también una aplicación móvil
que trata de comunicarse a una IP a través también de TCP/IP y HTTPS. Todo esto
define algo genérico que si nos permite reutilizarlo a través de diferentes
softwares, nos va a ayudar a poder reutilizar este conocimiento y aprender de
soluciones anteriores que tuvieron éxito implementando esas comunicaciones o
esos componentes con esos conectores. Si tuviéramos que bajarlo a una definición
podemos decir que un estilo de arquitectura es una colección de decisiones
arquitectónicas o decisiones de diseño que dado un contexto nos permite ya
restringir las decisiones arquitectónicas, es decir, nos da un set de decisiones ya
tomadas y nos restringe el resto de las decisiones arquitectónicas para un
beneficio ya estimado, podemos usar estas decisiones ya tomadas en el pasado y

J.A.G.H PÁGINA 12
Teoría
Arquitectura de Software Empresarial IS-602

que tuvieron éxito y aplicarlas en nuestro sistema que comparte un sistema

general similar y esperar tener un éxito parecido al que tuvo quien lo implemento
anteriormente.

2. Estilo: Llamado y retorno

Programa principal y subrutinas
Al principio en la programación había instrucciones ejecutadas secuencialmente.
En medida que los programas se fueron complejizando era necesario re utilizar
bloques de programa, entonces se hacían instrucciones de salto, la abstracción de
eso fueron las subrutinas o funciones. Es el estilo más básico evolucionado de un
script. Se siguen viendo en contextos de scripting para despliegues, por ejemplo.
Orientado a objetos
Es un estilo muy común y se usan para hacer aplicaciones que ya sabemos que
vamos a necesitar mantener por mucho tiempo. Tratamos de juntar el estado de
la aplicación con el comportamiento asociado a ese estado en particular, por lo
tanto, creamos objetos que van a tener un comportamiento específico y un estado
interno.
Multi-nivel
Tenemos diferentes componentes que se comunican entre sí en un orden
específico. Pueden ser un mismo programa o múltiples programas que se ejecutan
independientemente. Un caso específico son las arquitecturas cliente – servidor.

3. Estilo: Flujo de datos

Este estilo se utiliza cuando tenemos un proceso que tiene que tener una salida
clara; pero esa misma salida puede segmentarse en partes. Partes que ya se sabe
que hay que hacer.
Lote Secuencial:
Se trata de la ejecución de una pieza de código, Ya procesa y asegurase de que
esta pase a otra etapa o proceso.

J.A.G.H PÁGINA 13
Teoría
Arquitectura de Software Empresarial IS-602

Tubos y Filtros:
Es un String o un flujo de datos continuo, en donde cada aplicación recibe esos
datos. los procesa. y los envía como salida a otra aplicación o quizás. ya hasta al
final de la ejecución.

4. Estilo: Centrado en datos

La aplicación va a tener múltiples componentes, pero algunos se va a concentrar
en cómo hacer para almacenar los datos, ponerlos disponibles y sean correctos
(pertinentes). Siempre vamos a considerar cómo hacer o guardar algo.

Tenemos los siguientes tipos:

Pizarrón:
El estilo pizarron se puede usar cuando se espera que diferentes partes de un
proceso terminen de procesar la información para después hacer algo con ella. Por
ejemplo un dashboard que toma datos procesados en tablas dinámicas para
mostrar los charts.
Módulos que le entregan a un sistema central.
Centrado en Base de Datos:
Diferentes aplicaciones usan la misma base de datos. Cualquiera de los
componentes deciden escribir a la base de datos, y no están conectadas entre si,
aunque pertenezca a un mismo sistema monolítico.Dependiendo del nivel en que
se encuentre el monolito es pertinente evaluar que hacer con este, si disgregarlo
o no.
Sistema experto o basado en reglas:
Componente cliente revisa si es una regla o una consulta, estas inferencias a
medida que las vamos procesando se agregan en una base de conocimientos que
luego podemos usar mediante consultas, por ejemplo los sistemas de inteligencia
artificial que aprenden de datos de entrada y que luego consultan para ejecutar n-
operación.
En los sistemas expertos, la parte de “inferir regla” se le podría llamar "motor de
inferencia". El motor de inferencia, a partir de los datos ingresados por un experto

J.A.G.H PÁGINA 14
Teoría
Arquitectura de Software Empresarial IS-602

(de ahi el nombre), por ejemplo, unos datos determinados correspondieron a un

valor determinado; plantea y registra unas reglas (genera la KB), “entrena” el
sistema, de tal manera que esta base de conocimiento KB, el “entrenamiento” se
pone a prueba con otros datos ingresados ya no por un experto sino ante una
situación desconocida/nueva.

5. Estilo: Componentes independientes

Existen dos grandes familias que tienen que ver con la forma en que se comunican
los componentes. (la invocación implicaita y explícita)
Invocación implícita:
Se tienen varios componentes y se cuenta con un BUS de eventos en el cual los
componentes van a escribir algunos eventos y luego el BUS los comunica a los
componentes que les conciernan dichos eventos. Existen varios tipos de BUS.
Tipos de BUS:
Publicar/suscribir: en donde el componente inicial es el que publica un evento y
los componentes que estan suscritos reciben la notificación de dicha publicación.
Orientado a servicios (Enterprise Service BUS): en este caso el BUS es un
componente inteligente, en el que los componentes notifican al BUS a través de
eventos y el BUS decide a quien notificar dichos eventos.

Invocación explícita:
Se tienen componentes desarrollados individualmente pero que todos se conocen
entre sí, dichos componentes tiene que publicar que via de comunicación existirá
para comunicarse entre ellos y a que se dedica cada uno.

6. Comparando estilos
Estilos monolíticos
Estilos donde se despliegan un artefacto de software

J.A.G.H PÁGINA 15
Teoría
Arquitectura de Software Empresarial IS-602

Eficiencia: Al tener un solo artefacto se puede ser optimizado de manera más

personalizada. // En estilos distribuido, es un problema debido a los canales de
comunicación, red, intenet que comunican los componentes.
Curva de aprendizaje: El monolitico contiene toda la información allí. Un
monolitico bien diseñado permite tener todas las piezas en el mismo lugar, por lo
que se facilita la lectura y entendimiento. // El el caso distribuido hay que entender
cada componente.Nota: Un componente interno en un distribuido puede ser visto
como un monolítico. Es la base de los microservicios.

Capacidad de prueba: Son más fáciles de probar una funcionalidad de principio a

fin. En distribuidos necesito tener todos lso componentes disponibles, incluyendo
los BUS de eventos.

Capacidad de modificación: Un cambio que se despliega todo junto garantiza

menos estaddos intermedios. Las versiones nunca coexisten en paralelo. En
distribuidos diferentes compoentes tienen diferentes versiones, por lo que
requiere de compatibilidad entre versiones. Una modificación en un distribuido es
más difícile hacer llegar.

Estilos distribuidos
Componentes que luego de ser desplegados se conectan de alguna forma.

Modularidad: Es separar componentes que prestan servicios

Disponibilidad: Es mayor que en monolítica, podemos tener multiples copias de

un componente, que esté disponible significa que sea más barato, tener una copia
entera de un monolitco es mucho más caro que copiar el componente distribuido
que necesitamos que escale. Microservicios aprovecha recursos.
Uso de recursos: Es más fácil gestionar los recursos del sistema
Adaptabilidad: Al ser distribuido se puede detewctar mucho más fácil qué
componente necesita ser adaptado del sistema y es más fácil de realizar esa

J.A.G.H PÁGINA 16
Teoría
Arquitectura de Software Empresarial IS-602

actualización paralela, en monolítos puede ser mucho más complicado, como

lanzar una app en un sistema operativo diferente.

¿Como elijo qué necesito?

Tener en cuenta los requisitos, los objetivos de negocio / arquitectura de software,
atributos de calida/ Estrategias de arquitectura, Escenarios/ Desiciones
arquitectonicas. Con el fin de analizar que sacrificios, riesgos y no riesgos cuento y
como impacta en mi proyecto

J.A.G.H PÁGINA 17