ARQUITECTURA
DE SOFTWARE Y AGILIDAD
INTEGRANTES
Álvaro
Pinilla
Eduardo
López
Alexis
Miranda
DOCENTE
Erwin
Fischer
CURSO
- SECCION
Tecnología
Computacional e Informática
FECHA
01-07-2013
Contenido
Introducción
En
el siguiente trabajo se investigará sobre “arquitectura de software y
agilidad”, tema designado a nuestro grupo. Este trabajo corresponde a la prueba
número dos del curso “Tecnologías Computacionales e Informáticas”.
Nos
enfocaremos principalmente en el artículo publicado por el Sr. Rodrigo Salinas,
“Una nueva arquitectura”, el cual ha sido trabajo en clases. Trataremos temas
como: cuál es la arquitectura correcta que debe tener un software, las buenas prácticas para realizar esto,
hacia dónde va el enfoque hoy en día, entre otros. Con el objetivo de conocer y
entender un poco más lo que realmente significa el término de “agilidad”, y su
relevancia en la arquitectura de software, así como también mejorar nuestras
capacidades al momento de enfrentarnos al desarrollo de algún software el día
de mañana.
Una nueva arquitectura.
Este es el
nombre de un artículo publicado por el Sr. Rodrigo Salinas, en el cual nos
enfocamos principalmente para realizar nuestra investigación. Gracias al
prestigio que este señor ha ganado con el tiempo está realizando constantemente
capacitaciones sobre este tema, en el cual recalca como primer punto que no
existe ninguna “nueva arquitectura”.
1-
Nombres nuevos, conceptos antiguos.
Como se
mencionaba anteriormente, no existe en realidad una “nueva arquitectura, lo que
hay es simplemente una mayor claridad respecto de cómo aplicar correctamente
conceptos teóricos que llevan por lo menos dos décadas tratando de imponerse en
la mente de los profesionales informáticos, desgraciadamente aún no se logra
comprender y aceptar de forma esperada estos nuevos conceptos.
Una arquitectura
correcta de software debe “gritar” o hacer saltar a la vista su tema principal.
El “plano” de cada sistema debe hacer que salte a la vista los elementos más
importantes de sus casos de uso. Para lo cual debemos hacer uso de un lenguaje
semántico adecuado, como DDD o UML por ejemplo, las principales entidades,
junto con sus más importantes operaciones, estarían ubicadas dentro de un
modelo que mostrara claramente su relación con el contexto donde existieran.
2-
Qué no debería afectar tu
arquitectura.
Lo primero que
se debe tener claro es que lo más
importante en cualquier proyecto de desarrollo de software es poder definirlo a
un nivel de abstracción independiente de motores de bases de datos, de sistemas
operativos, lenguajes de programación o frameworks. Ninguna de estas cosas debe
de importar al momento de definir una arquitectura.
La tendencia
natural de las personas que trabajan en el área de la informática es
“enamorarse” de los frameworks, lenguajes, tecnologías y paradigmas. Aprendemos
un conjuntos de herramientas con las que logramos tener un cierto éxito en
algún proyecto, para luego, cuando se nos presenta un nuevo proyecto buscar
hacer uso de las mismas herramientas una y otra vez. No obstante este no viene
siendo el mayor problema, el problema es que tendemos a diseñar nuestras
soluciones en función de dichas herramientas.
El enamoramiento
tecnológico se produce principalmente por dos razones:
-
Profesionales
jóvenes descubren algún framework o herramienta que les permite crear todo
aquello que no tenían idea de cómo hacerlo. Se descubren herramientas que nos
permiten hacer todo más rápido, de forma más simple y con “buenos” resultados y
se hace muy difícil mirar a otro lado.
-
Profesionales
con más experiencia se preocupan más por el resto del “ciclo de vida” de la
aplicación. Se preocupan que vayan a encontrar, en el mercado, profesionales no
muy costosos que puedan mantenerlas, de contar con empresas serias que entreguen
un buen soporte. Por lo tanto se seleccionan herramientas ya probadas y que
llevan más tiempo implementándose, ya que esto las hace más “confiables”
Lo que termina
por ocurrir es que algunas de estas dos visiones mencionadas anteriormente terminan
interponiéndose en el camino de la elección de la mejor arquitectura para el
desarrollo del software.
3- Considera la historia.
La llegada del
internet revoluciono a las empresas, estas empezaron a desarrollar una capa de
aplicaciones para la web, con esto se llegaron a probar diversas tecnologías y
técnicas hasta encontrar aquellas que más les acomodaban. Estas aplicaciones
para la Web fueron, durante al menos los últimos 10 años, un mundo aparte
dentro de TI en la mayoría de las empresas, no sintieron nunca que la Web en
realidad les iba a tocar el core de sus aplicaciones ya existentes. Siguieron
coexistiendo ambos mundos y evolucionando por separado.
4- Los nuevos clientes/usuarios y la
transmedia.
Debemos ser
capaces de entender que hoy en día los clientes ya se sienten usuarios y no solo
simples clientes. Del mismo modo que años atrás se hizo evidente la necesidad
de cada empresa por poseer un sitio en la Web, hoy es mal mirado el que alguna
empresa no tenga aplicaciones de auto atención disponibles en la Web. Los
clientes lo que quieren es ser usuarios de estas aplicaciones, quieren contar
con funcionalidades de consulta de precios o de contratación de servicios o
productos, quieren consultar estados de cuenta, quieren ver sus detalles de
consumo, quieren pagar sus cuentas, quieren comprar y vender, quieren opinar,
quieren consultar bases de datos de conocimiento para descubrir cómo resolver
posibles problemas con los productos o servicios contratados. Estos nuevos
clientes/usuarios quieren todos estos nuevos servicios disponibles en sus PC’s
del trabajo, en sus casas, en sus plasmas y en sus dispositivos móviles. Lo
quieren ahora y lo quieren ya.
La transmedia,
según Martin Fowler, se refiere a la experiencia del usuario que hace uso de
distintos dispositivos, en diferentes contextos, de una misma aplicaciones, ya
sea un su escritorio, como en su Tablet o su Smartphone, estos deben ser
capaces de proporcionar una experiencia similar con la aplicación, obviamente
propias del contexto en el que se encuentre el usuario.
Tenemos hoy en
día un cliente/usuario que quiere funcionalidad sobre la Web, que se le
proporcione la sensación de “yo tengo el control”. Y en esto tiene razón,
vivimos en un mundo globalizado y tecnológico, por lo tanto es justo esperar
que los proveedores tradicionales se pongan a la altura de los tiempos
modernos.
5-
La arquitectura correcta.
Hoy en día
podemos ver sitios Web con funcionalidad pobre e insuficiente, son lentos y a
menudo se caen de las maneras menos elegantes posibles, esto debido a que si
bien son conscientes de que necesitan de estas funcionalidades en sus Web,
sucede que en ambiente de producción han descubierto de que no son capaces de
ofrecer un nivel de desempeño aceptable.
Esto se debe a
que su arquitectura modular se interpone como una gran limitante, se estima que
durante los últimos 15 años se han venido desarrollando el software de negocios
bajo premisas y prioridades equivocadas. Se han descuidado dos principios
básicos para que una arquitectura sea verdaderamente escalable, fácilmente
mantenible y altamente extensible.
a)
Arquitectura armada a partir de bloques de abstracción adecuados: Hasta hoy en día la abstracción que más se maneja en la mayoría
de las empresas es la DATA, y es un error que la DATA sea el centro del
universo.
Ni muy cerca de la DATA: La lógica de negocios muchas veces se ejecuta en el
lugar más rápido pero a su vez el menos escalable de todos, el servidor de la
Base de Datos. El gran problema de estas BD relacionales es que estas no son
capaces de sacarle provecho a la escalabilidad horizontal, y hoy en día se
sufren las consecuencias, de toda esa cantidad de información que se ha
almacenado por años en las maquinas encargadas de las BD, constantemente se
tiene que estar invirtiendo en servidores capaces de atender un nivel de
demanda altísimo, y en ocasiones, con poco éxito.
Si sabemos que
nuestros servidores de BD son limitados, deberíamos estar preocupados de
quitarles responsabilidad, pero ¿qué hacemos entonces con la lógica de
negocios?, ¿Dónde la llevamos? Debemos llevarlas a modelos de dominio que
pueden ser ejecutados en forma distribuida y replicada en granjas de servidores
o Clouds de máquinas baratas y fácilmente administrables.
Ni muy cerca del usuario: No debemos de situar la lógica del negocio en el
mismo frontend de las aplicaciones, ni tampoco repetir una y otra vez la lógica
del dominio en incontables lugares. Esto puede llevar a la sobre exigencia de una
máquina y, en otros casos, se dificulta la mantenibilidad de las reglas del
negocio. Cuando TI teme realizar cambios debido a que no conoce los reales
impactos, quien sufre es el negocio directamente ya que no cuenta con la
versatilidad necesaria para mantenerse en el mundo competitivo en el que nos
encontramos hoy.
Entonces ¿Cuál debería
ser nuestro centro del universo? Existe un nivel de abstracción mucho más útil,
escalable, extensible y reutilizable que tan solo tablas y procedimientos
almacenados. Es la abstracción de entidades junto a la lógica encapsulada en
ellas, el conjunto de estas abstracciones se conoce como “Modelo del Dominio”,
este es un concepto antiguo, pero aun no nos acostumbramos realmente a trabajar
a este nivel de abstracción a escala corporativa.
Domain-Driven Desing: Hoy en día es el approach a la Ingeniería de
Software que mejor guía ofrece respecto de cómo representar el conjunto
completo de sistemas computacionales en una empresa, bajo un modelo de abstracción
orientado a las principales entidades y contextos de un dominio.
b) Conceptual y tecnológicamente independiente:
Ya vimos que una
arquitectura correcta se arma a partir de bloques de abstracción adecuados. El
segundo principio básico a cumplir es el desacoplamiento conceptual y tecnológico
de nuestra Arquitectura. Los aspectos fundamentales que debe proporcionar un
estilo de arquitectura son los siguientes:
- Independiente
de frameworks.
- Testeable.
-Independiente
de la interfaz de usuario.
-Independiente
de la base de datos.
Cabe recalcar de
entre todos estos aspectos fundamentales, la importancia de diseñar y construir
unidades de software en conjunto con test unitarios automatizados que las
ejecuten.
Arquitectura orientada a servicio de cliente (SOA).
Primero que todo
¿Qué es SOA?: Es un concepto de arquitectura de software que define
la utilización de servicios para dar soporte a los requisitos del negocio.
Permite la
creación de sistemas de información altamente escalables que reflejan el
negocio de la organización, a su vez brinda una forma bien definida de
exposición e invocación de servicios (comúnmente pero no exclusivamente servicios
web), lo cual facilita la
interacción entre diferentes sistemas propios o de terceros.
Al contrario de
las arquitecturas orientado a objetos, las SOAs están formadas por servicios de
aplicación débilmente acoplados y altamente interoperables. Para comunicarse
entre sí, estos servicios se basan en una definición formal independiente de la
plataforma subyacente y del lenguaje de programación. La definición de la
interfaz encapsula (oculta) las particularidades de una implementación, lo que
la hace independiente del fabricante, del lenguaje de programación o de la
tecnología de desarrollo (como Plataforma Java o Microsoft .NET). Con esta
arquitectura, se pretende que los componentes de software desarrollados sean
muy reutilizables, ya que la interfaz se define siguiendo un estándar; así, un
servicio C# podría ser usado por una aplicación Java. En este sentido, ciertos
autores definen SOA como una Súper-Abstracción.
Cuando los
profesionales de la informática se dieron cuenta de que los mundos del
Backoffice y la Web debían comunicarse, empezó la fiebre de SOA. De hecho casi
todo el mundo vivió prácticamente lo mismo:
Partieron
implementando los populares Web Services SOAP (Simple Object Access Protocol).
Esta tecnología les permitió a todos rápidamente hacer que sus mundos
interoperaran. Como suele pasar a toda solución simple y económica,
evidentemente abusamos de ella. Al poco tiempo pulularon por todas partes estor
servicio y se perdió su control. Muchos ya no sabían que realmente hacia un
determinado servicio o como reutilizarlo.
La preocupación general
ahora paso a ser la gubernabilidad de los servicios (SOA Governance). Como
administrar sus ciclos de vida desde un único lugar. Todos empezaron a mirar a
los Enterprise Service Buses de IBM, Oracle y en unos cuantos casos a Microsoft
como la solución a todos sus problemas, de alguna u otra manera las empresas lograron
controlar sus Web Services.
No obstante
superados estos problemas, apareció uno mucho mayor, que las demandas de los
clientes estaban en alza respecto a este tema, lo que tratamos anteriormente en
el punto “Los nuevos clientes/usuarios y la transmedia”.
No podemos
hablar de Arquitectura de Software Corporativo hoy en día sin explicar su relación
con el Movimiento Ágil. Una de las personas no informáticas que más ha
influenciado el actual pensar de la Ingeniería de Software, o del diseño en
general, es Christopher Alexander. Él ha propuesta teorías originales
aplicables al diseño y a la arquitectura. Las ideas de este arquitecto civil
austriaco han proporcionado un fundamento teórico potente para nuevas prácticas
relacionadas con la construcción de software. A diferencia de las metodologías tradicionales
donde el software es diseñado completo al principio, para luego ser construido
a partir de la documentación del diseño, estas nuevas prácticas apuntan a
ciclos incrementales, orgánicos y coherentes de construcción de software, con
una fase de diseño por cada una de estas iteraciones. Debemos ser capaces de
diferenciar entre un diseño incremental versus uno iterativo.
El movimiento ágil
ha transformado completamente la manera de hacer Arquitectura de Software, este
movimiento no ha eliminado el diseño, lo que ha eliminado es la ilusión de que
es posible diseñar completamente un sistema antes de empezar su construcción. La
arquitectura ya no es una especificación a priori, sino una visión de un estado
futuro del sistema.
Esta nueva visión
sirve de guía para cada iteración de diseño-construcción-entrega. Se habla de iteración
porque, especialmente en un sistema complejo, no es práctico pretender realizar
un único salto desde el estado inicial hacia el estado final deseado. Debe
haber pasos o estados intermedios pequeños pero completos a la vez. En cada uno
de estos pasos o ciclos se añade al sistema funcionalidad útil y verificable
por el usuario, al empezar el siguiente ciclo, diseñaremos a partir de lo
anterior que construimos, tomando en consideración las lecciones aprendidas,
realizando los ajustes necesarios, pero jamás olvidando la visión que nos
proporciona la Arquitectura del Sistema que nos dice hacia donde nos dirigimos.
El diseño
evolutivo, cuando es enmarcado en una estricta disciplina y es realizado por
todo el equipo de desarrollo e conjunto con testers y usuarios, produce éxito.
Agilidad en las empresas.
Los críticos del
desarrollo ágil suelen tener la
opinión que enfoques iterativos como Scrum no pueden ser aplicados a grandes empresas, pues consideran que
los proyectos de software de estas requieren de cientos de personas que sólo
pueden gestionarse en una estructura jerárquica centralizada.
Sin embargo, a pesar de esta opinión existen ejemplos de grandes empresas que han aplicado con éxito la agilidad, uno de esos casos es el de Amazon.com
Sin embargo, a pesar de esta opinión existen ejemplos de grandes empresas que han aplicado con éxito la agilidad, uno de esos casos es el de Amazon.com
Amazon comenzó
como una sola aplicación comunicándose con un Backend, pero eventualmente
creció hasta convertirse en una plataforma de servicios totalmente distribuida
y centralizada, prestando servicios a diferentes aplicaciones.
Hoy en día, la arquitectura de Amazon tiene bajo grado de acoplamiento y está construida alrededor de servicios. Está arquitectura orientada a servicios es la que les permite construir muchos componentes de software, de forma rápida e independiente.
La arquitectura de Amazon ha crecido hasta tener cientos de servicios y múltiples servidores de aplicaciones. Estos servidores de aplicaciones son los que proporcionan estos servicios. Por ejemplo, la aplicación que presenta la página Amazon.com es uno de esos servidores de aplicaciones. Asimismo, existen otros servidores, específicamente: Servidores para interfaces de servicios web (Web Servers), la aplicación de servicio al cliente y la interfaz para vendedores.
Hoy en día, la arquitectura de Amazon tiene bajo grado de acoplamiento y está construida alrededor de servicios. Está arquitectura orientada a servicios es la que les permite construir muchos componentes de software, de forma rápida e independiente.
La arquitectura de Amazon ha crecido hasta tener cientos de servicios y múltiples servidores de aplicaciones. Estos servidores de aplicaciones son los que proporcionan estos servicios. Por ejemplo, la aplicación que presenta la página Amazon.com es uno de esos servidores de aplicaciones. Asimismo, existen otros servidores, específicamente: Servidores para interfaces de servicios web (Web Servers), la aplicación de servicio al cliente y la interfaz para vendedores.
Conclusiones.
Para todo lo que
tenga que ver con el Software Estratégico de una compañía, aquel que soporta
las funciones de negocio que la diferencian de su competencia, es
imprescindible que desde ya esa empresa, si pretende ser líder en su rubro de
aquí a 5 años, esté invirtiendo en evolucionar su Arquitectura actual hacia lo
que hemos definido en este post como una Arquitectura Correcta.
Correcta no
desde el punto de vista académico solamente, no por moda o por capricho, sino
por los evidentes beneficios prácticos que he intentado explicar brevemente en
este post: mejorar el desempeño al aprovechar el escalamiento horizontal (más
máquinas pero a la vez más económicas), reducir costos al desarrollar y
mantener los sistemas (modelos de dominio centralizados más simples de
modificar y extender) y facilitar la implementación de nueva funcionalidad al
separar responsabilidades en el software a nivel corporativo.
Todo esto sin
olvidar que la Arquitectura no es una especificación congelada sino una Visión
que evoluciona en el tiempo, con la participación colectiva de todas las
personas involucradas en los procesos del negocio: desarrolladores, testers,
ejecutivos y usuarios. Todos trabajando para la felicidad de estos últimos.
Propuestas de Preguntas.
1)
¿Cuál es el
rol del arquitecto de software, en agilidad?
R: Dentro de la agilidad este rol se pierde un poco,
ya que el equipo completo debe estar integrado dentro de este proceso, aportando
ideas y mejoras en la App. Deben aportar con nuevas tecnologías que permiten la
escalabilidad de la aplicación y la fácil integración de nuevos cambios dentro
del software, sin la necesidad de hacer refactorización, lo que puede resultar
costoso.
2)
¿Es necesario “inventar” una arquitectura de
software nueva para cada sistema de información?
R: No, lo habitual es adoptar una arquitectura
conocida en función de sus ventajas e inconvenientes para cada caso en concreto.
Dado esto existen ciertas arquitecturas universales como: Cliente-servidor,
modelo vista y controlador, arquitectura de tres niveles, entre otras.
3)
¿SOA es lo mismo que Cloud Computing?
R: Aunque hay algunas ideas que subyacen en la definición
de ambos términos, como el uso del concepto de servicio o la idea de la
independencia de localización de los mismos, queda claro que los ámbitos de aplicación
son distintos, relacionándose SOA con el ámbito del desarrollo de aplicaciones
TI con claro significado de negocio, mientras que Cloud se refiere más a la
forma de ofertar recursos TI a cliente final, a su entrega, provisión, y
posterior gestión y operación.
Referencias.
Siglas.
DDD: Domain-driven desing; Diseño orientado al dominio.
UML: Unified
Modeling Language; Lenguaje de Modelado Unificado.
TI:
Tecnologías de información.
SOA:
Service-oriented architecture; Arquitectura orientada al servicio.
SOAP: Simple Object Access Protocol;
Links de presentacion e informe.
Presentacion Power Point:
https://www.dropbox.com/s/2wfziqhp6g03erg/ArquitecturaAgilidad.ppt
Informe Word:
https://www.dropbox.com/s/s3xtbbz1e0a9zpr/ArqAgilidad.docx
Links de presentacion e informe.
Presentacion Power Point:
https://www.dropbox.com/s/2wfziqhp6g03erg/ArquitecturaAgilidad.ppt
Informe Word:
https://www.dropbox.com/s/s3xtbbz1e0a9zpr/ArqAgilidad.docx
