CAPITULO 1

Comprensión de la arquitectura de software

1.1 Qué es la Arquitectura de software.

Los últimos 15 años han visto un tremendo aumento en la prominencia de un software
subdisciplina de ingeniería conocida como arquitectura de software. Arquitecto Técnico y
Arquitecto jefe son títulos de trabajo que abundan ahora en la industria del software. Hay
un Asociación Internacional de Arquitectos de Software, e incluso un conocido El friki más
rico del mundo solía tener "arquitecto" en su puesto de trabajo en su mejor momento.
¿No puede ser un mal concierto, entonces?
Tengo la ligera sospecha de que la "arquitectura" es una de las más utilizadas y términos
menos comprendidos en los círculos profesionales de desarrollo de software. Lo escucho
utilizado habitualmente en foros tan diversos como revisiones y debates de proyectos,
Presentaciones de trabajos académicos en conferencias y presentaciones de productos.
Sabes un El término se está volviendo gradualmente vacío cuando se convierte en parte
de la lengua vernácula de la fuerza de ventas de la industria del software.
Este libro trata sobre arquitectura de software. En particular, se trata del diseño clave y
cuestiones tecnológicas a considerar al construir sistemas del lado del servidor que
procesan solicitudes múltiples y simultáneas de usuarios y / u otros sistemas de software.
Su objetivo es Describir de manera concisa los elementos esenciales del conocimiento y
las habilidades clave que requerido para ser un arquitecto de software en el software y la
tecnología de la información (TI) industria. La concisión es un objetivo clave. Por esta
razón, de ninguna manera todo un El arquitecto necesita saber que se cubrirá. Si quiere o
necesita saber más, cada Este capítulo le indicará recursos adicionales valiosos y útiles que
pueden llevar a mayor iluminación.
Así que, sin más preámbulos, intentemos averiguar qué software, al menos yo creo, la
arquitectura realmente lo es y, lo que es más importante, no lo es. El resto de este
capítulo abordar esta pregunta, así como presentar brevemente las principales tareas de
un arquitecto, y la relación entre arquitectura y tecnología en aplicaciones de TI.
1.2 Definiciones de Arquitectura de Software
Tratar de definir un término como arquitectura de software es siempre una potencial
actividad peligrosa. Realmente no existe una definición ampliamente aceptada por la
industria. Para comprender la diversidad de puntos de vista, examine la lista que mantiene
el Instituto de Ingeniería de Software. Hay mucho. Leer estos me recuerda a una cita
anónima que escuché en un programa de radio satírico recientemente, que fue algo en la
línea de “la razón por la que el debate académico es tan vigoroso es que hay tanta poco
en juego”.
No tengo la intención de agregar algo a este debate. En cambio, examinemos tres
definiciones. Como miembro de IEEE, naturalmente empiezo con la definición adoptada
por mi cuerpo profesional:
La arquitectura se define por la práctica recomendada como la organización fundamental
de un sistema, incorporado en sus componentes, sus relaciones entre sí y con su
ambiente, y los principios que rigen su diseño y evolución.
Esto sienta las bases para una comprensión de la disciplina. Arquitectura captura la
estructura del sistema en términos de componentes y cómo interactúan. También define
las reglas de diseño de todo el sistema y considera cómo puede cambiar un sistema.
A continuación, siempre vale la pena obtener la última perspectiva de algunos de los
principales pensadores en el campo.
La arquitectura de software de un programa o sistema informático es la estructura o
estructuras del sistema, que comprende elementos de software, las propiedades visibles
externamente de aquellos elementos y las relaciones entre ellos.
Esto se basa en cierta medida en la definición ANSI / IEEE anterior, especialmente porque
hace el papel de la abstracción (es decir, propiedades visibles externamente) en una
arquitectura y múltiples vistas de arquitectura (estructuras del sistema) explícitas.
Compare esto con otro, del influyente trabajo temprano de Garlan y Shaw:
[La arquitectura del software va] más allá de los algoritmos y las estructuras de datos de la
computación; El diseño y la especificación de la estructura general del sistema surge como
un nuevo tipo de problema. Los problemas estructurales incluyen la organización general
y la estructura de control global; protocolos para comunicación, sincronización y acceso a
datos; asignación de funcionalidad al diseño elementos; distribución física; composición
de elementos de diseño; escalamiento y desempeño; y selección entre alternativas de
diseño.
Es interesante verlos, ya que hay muchos puntos en común. Yo incluyo el tercero,
principalmente porque vuelve a ser explícito sobre ciertos problemas, como la
escalabilidad y distribución, que están implícitas en los dos primeros.
Independientemente, analizando estos poco permite extraer algunas de las características
fundamentales de arquitecturas de software. Estos, junto con algunos enfoques clave, se
describen debajo.
1.2.1 La arquitectura define la estructura
Gran parte del tiempo de un arquitecto se ocupa de cómo dividir con sensatez una
aplicación en un conjunto de componentes interrelacionados, módulos, objetos o
cualquier unidad de la partición de software funciona para usted. Diferentes requisitos y
con- Las limitaciones definirán el significado preciso de "sensatamente" en la oración
anterior una La arquitectura debe diseñarse para cumplir con los requisitos y limitaciones
específicos de la aplicación a la que está destinado.
Por ejemplo, un requisito para un sistema de gestión de la información puede ser que la
aplicación se distribuye en varios sitios, y una restricción es que la funcionalidad y los
datos deben residir en cada sitio. O la funcionalidad de una aplicación debe ser accesible
desde un navegador web. Todos estos imponen algunas con- restricciones (sitio
específico, servidor web alojado), y simultáneamente abren vías para considerable
creatividad de diseño en la funcionalidad de partición en una colección de componentes
relacionados.
Al dividir una aplicación, el arquitecto asigna responsabilidades a cada componente
constituyente. Estas responsabilidades definen las tareas que un componente puede se
puede confiar en que funcionará dentro de la aplicación. De esta manera, cada
componente juega un papel específico en la aplicación, y el conjunto de componentes
general que comprende la arquitectura colabora para proporcionar la funcionalidad
requerida.
El diseño impulsado por la responsabilidad (ver Wirfs-Brock en Lecturas adicionales) es
una tecnología ni que de la orientación a objetos que se puede utilizar eficazmente para
ayudar a definir la clave componentes en una arquitectura. Proporciona un método
basado en herramientas informales y técnicas que enfatizan el modelado del
comportamiento utilizando objetos, responsabilidades y colaboraciones. Encontré esto
extremadamente útil en proyectos anteriores para estructurar componentes a nivel
arquitectónico.
Un problema estructural clave para casi todas las aplicaciones es minimizar las
dependencias entre componentes, creando una arquitectura débilmente acoplada a partir
de un conjunto de componentes cohesivos. Existe una dependencia entre componentes
cuando un cambio en uno fuerza potencialmente un cambio en otros. Eliminando
dependencias innecesarias, los cambios se localizan y no se propagan a través de una
arquitectura (ver Figura 1.1).
Las dependencias excesivas son simplemente algo malo. Hacen que sea difícil de hacer
cambios en los sistemas, más costosos para probar los cambios, aumentan los tiempos de
construcción y hacen que el desarrollo concurrente basado en equipos sea más difícil.
1.2.2 La arquitectura especifica la comunicación de componentes
Cuando una aplicación se divide en un conjunto de componentes, es necesario Piense en
cómo estos componentes comunican datos y controlan la información. Los componentes
de una aplicación pueden existir en el mismo espacio de direcciones y comunicaciones a
través de llamadas de método sencillas. Pueden ejecutarse en diferentes subprocesos o
procesos y comunicarse a través de mecanismos de sincronización. O múltiples Los
componentes pueden necesitar ser informados simultáneamente cuando ocurre un
evento en el entorno de la aplicación. Hay muchas posibilidades.
Un cuerpo de trabajo conocido colectivamente como patrones o estilos arquitectónicos4
ha catalogó una serie de estructuras utilizadas con éxito que facilitan ciertos tipos de
comunicación de componentes [consulte Patrones en lecturas complementarias]. Estos
patrones son planos arquitectónicos esencialmente reutilizables que describen la
estructura y la interacción entre colecciones de componentes participantes.
Cada patrón tiene características bien conocidas que lo hacen apropiado para usar en
satisfaciendo tipos particulares de requisitos. Por ejemplo, el patrón cliente-servidor
tiene varias características útiles, como la comunicación de solicitud-respuesta síncrona de
cliente a servidor, y servidores que dan soporte a uno o más clientes a través de una
interfaz publicada. Opcionalmente, los clientes pueden establecer sesiones con
servidores, que puede mantener el estado sobre sus clientes conectados. Las
arquitecturas cliente-servidor también proporcionan un mecanismo para que los clientes
ubiquen servidores, manejen errores y, opcionalmente, proporcionar seguridad en el
acceso al servidor. Todos estos problemas se tratan en el cliente-servidor. patrón de
arquitectura.
El poder de los patrones de arquitectura se deriva de su utilidad y capacidad para
transmitir información de diseño. Se ha demostrado que los patrones funcionan. Si se usa
apropiadamente en una arquitectura, aprovecha el conocimiento de diseño existente
mediante el uso de patrones. Los sistemas grandes tienden a utilizar múltiples patrones,
combinados de manera que satisfagan los requisitos de arquitectura. Cuando una
arquitectura se basa en patrones, también resulta fácil para los miembros del equipo
comprender un diseño, ya que el patrón infiere estructura de componentes,
comunicaciones y mecanismos abstractos que deben ser previsto. Cuando alguien me dice
que su sistema se basa en un cliente-servidor de tres niveles arquitectura, sé
inmediatamente una cantidad considerable sobre su diseño. Esto es un mecanismo de
comunicación muy poderoso de hecho.
1.3 La arquitectura aborda los requisitos no funcionales
Los requisitos no funcionales son los que no aparecen en los casos de uso. En vez de
definir lo que hace la aplicación, les preocupa cómo la aplicación proporciona la
funcionalidad requerida.
Hay tres áreas distintas de requisitos no funcionales:

 Restricciones técnicas: serán familiares para todos. Limitan el diseño opciones

especificando ciertas tecnologías que la aplicación debe utilizar. "Nosotros sólo
tenemos desarrolladores de Java, por lo que debemos desarrollar en Java”. "La
base de datos existente sólo se ejecuta en Windows XP”. Por lo general, no son
negociables.
 Restricciones comerciales: estas opciones de diseño demasiado restrictivas, pero
para las empresas, no razones técnicas. Por ejemplo, "Para ampliar nuestra base
de clientes potenciales, debemos interactuar con las herramientas XYZ”. Otro
ejemplo es “El proveedor de nuestro El middleware ha elevado los precios de
forma prohibitiva, por lo que nos cambiamos a un código abierto versión". La
mayoría de las veces, estos tampoco son negociables.
 Atributos de calidad: definen los requisitos de una aplicación en términos de
escalada capacidad, disponibilidad, facilidad de cambio, portabilidad, usabilidad,
rendimiento, etc. Los atributos de calidad abordan cuestiones de interés para los
 usuarios de la aplicación, así como otras partes interesadas, como el propio equipo
del proyecto o el patrocinador del proyecto. Capítulo 3 analiza los atributos de
calidad con cierto detalle.
Por lo tanto, una arquitectura de aplicación debe abordar explícitamente estos aspectos
del diseño. Los arquitectos deben comprender los requisitos funcionales y crear una
plataforma que los soporta y simultáneamente satisface los no funcionales requisitos.
1.3.1 La arquitectura es una abstracción
Una de las descripciones más útiles, pero a menudo inexistentes, de una arquitectura La
perspectiva es algo que se conoce coloquialmente como arquitectura de mercado. Este es
uno página, generalmente una descripción informal de la estructura y las interacciones del
sistema. Eso muestra los componentes principales y sus relaciones y tiene algunos
etiquetas y cuadros de texto que retratan las filosofías de diseño encarnadas en la
arquitectura ture. Una conferencia de marketing es un vehículo excelente para facilitar la
discusión por parte de las partes interesadas.
titulares durante el diseño, la construcción, la revisión y, por supuesto, el proceso de
venta. Es fácil de comprender y explicar y sirve como punto de partida para un análisis
más profundo. Una estructura de mercado cuidadosamente elaborada es particularmente
útil porque es una descripción abstracta del sistema. En realidad, cualquier descripción
arquitectónica debe Emplear la abstracción para ser comprensible para los miembros del
equipo y el proyecto. partes interesadas. Esto significa que los detalles innecesarios se
suprimen o ignoran en con el fin de centrar la atención y el análisis en los aspectos
arquitectónicos más destacados. Esto es normalmente se hace describiendo los
componentes de la arquitectura como cajas negras, especificando solo sus propiedades
visibles externamente. Por supuesto, describiendo el sistema estructura y
comportamiento como colecciones de abstracciones comunicantes de caja negra es
normal para los profesionales que utilizan técnicas de diseño orientado a objetos. Uno de
los mecanismos más poderosos para describir una arquitectura es la jerarquía
descomposición química. Los componentes que aparecen en un nivel de descripción son
descompuestos con más detalle en la documentación de diseño adjunta. Como examen,
Por ejemplo, la figura 1.2 muestra una jerarquía de dos niveles muy simple utilizando una
notación informal, con dos de los componentes en el diagrama de nivel superior
descompuestos aún más. Los diferentes niveles de descripción en la jerarquía tienden a
ser de interés para diferentes los desarrolladores en un proyecto. En la figura 1.2, es
probable que los tres componentes de la descripción de nivel superior será diseñada y
construida por diferentes equipos que trabajan en la
aplicación. La arquitectura divide claramente las responsabilidades de cada equipo,
definiendo las dependencias entre ellos. En este ejemplo hipotético, el arquitecto ha
perfeccionado el diseño de dos de los componentes, presumiblemente porque algunos
requisitos no funcionales dictan que Es necesaria una definición. Quizás deba utilizarse un
servicio de seguridad existente, o el corredor debe proporcionar una función de
enrutamiento de mensajes específica que requiera un servicio de directorio que tiene un
nivel conocido de rendimiento de solicitudes. Independientemente, este refinamiento
adicional crea una estructura que define y restringe el diseño detallado de estos
componentes. La arquitectura simple de la Fig. 1.2 no descompone el componente
Cliente. Esto se debe, nuevamente, presumiblemente, a que la estructura interna y el
comportamiento del cliente no es significativo para lograr los requisitos generales no
funcionales de la aplicación. La forma en que el cliente obtiene la información que se
envía al corredor no es un problema que incumbe al arquitecto y, en consecuencia, el
diseño detallado se deja abierto al equipo de desarrollo del componente. Por supuesto, el
componente Cliente podría posiblemente ser el más complejo de la aplicación. Podría
tener una arquitectura interna definida por su equipo de diseño, que cumple con los
objetivos de calidad específicos para el componente Cliente. Sin embargo, se trata de
preocupaciones localizadas. No es necesario que el arquitecto Complicar la arquitectura
de la aplicación con tales problemas, ya que se pueden dejar de manera segura. al equipo
de diseño del Cliente para resolverlo. Este es un ejemplo de la supresión de detalles en la
arquitectura.
1.3.2 Vistas de Arquitectura
Una arquitectura de software representa un artefacto de diseño complejo. No es de
extrañar entonces, como la mayoría de los artefactos complejos, hay varias formas de ver
y comprender de pie una arquitectura. El término "vistas de la arquitectura" saltó a la
fama en Artículo de 19955 de Philippe Krutchen sobre el modelo de vista 4þ1. Esto
presentó una forma de describir y comprender una arquitectura basada en los siguientes
cuatro puntos de vista:

 Vista lógica: describe los elementos arquitectónicamente significativos de la

arquitectura y las relaciones entre ellos. La vista lógica esencialmente captura la
estructura de la aplicación utilizando diagramas de clases o equivalentes.
 Vista de proceso: se centra en describir la simultaneidad y las comunicaciones
elementos de una arquitectura. En las aplicaciones de TI, las principales
preocupaciones son describir componentes multiproceso o replicados, y los
síncronos o asincrónicos Mecanismos de comunicación utilizados.
 Vista física: representa cómo los procesos y componentes principales se mapeado
en el hardware de las aplicaciones. Podría mostrar, por ejemplo, cómo La base de
datos y los servidores web de una aplicación se distribuyen en varias máquinas de
servidor.
 Vista de desarrollo: captura la organización interna del software componentes,
normalmente cuando se mantienen en un entorno de desarrollo o configuración
herramienta de gestión de la duración. Por ejemplo, la representación de un
paquete anidado y jerarquía de clases para una aplicación Java representaría la
vista de desarrollo de una arquitectura.
Estas vistas están unidas por los casos de uso de importancia arquitectónica (a menudo
escenarios escenarios). Básicamente, capturan los requisitos de la arquitectura y, por lo
tanto, están relacionados con más de una vista en particular. Al seguir los pasos de un
caso de uso particular, la arquitectura se puede "probar", explicando cómo el diseño Los
elementos de la arquitectura responden al comportamiento requerido en el caso de uso.
Bien explore cómo hacer esta "prueba de arquitectura" en el Cap. 5. Desde el artículo de
Krutchen, ha habido mucho pensamiento, experiencia y desarrollo en el área de vistas de
arquitectura. En particular, es el trabajo de la SEI, coloquialmente conocido como el
enfoque “Vistas y más allá” (ver Lecturas adicionales). Esto recomienda capturar un
modelo de arquitectura utilizando tres vistas diferentes:

 Módulo: esta es una vista estructural de la arquitectura, que comprende el código

módulos como clases, paquetes y subsistemas en el diseño. También captura
descomposición, herencia, asociaciones y agregaciones de módulos.
 Componente y conector: esta vista describe los aspectos de comportamiento de la
arquitectura. Los componentes suelen ser objetos, subprocesos o procesos, y los
 conectores describen cómo interactúan los componentes. Los conectores comunes
son sockets, middleware como CORBA o memoria compartida.
 Asignación: esta vista muestra cómo se asignan los procesos de la arquitectura a
hardware y cómo se comunican mediante redes y / o bases de datos. También
captura una vista del código fuente en los sistemas de gestión de la configuración,
y quién en el grupo de desarrollo tiene la responsabilidad de cada módulo.
La terminología utilizada en "Vistas y más allá" está fuertemente influenciada por la
comunidad de investigación del lenguaje de descripción de arquitectura (ADL). Esta
comunidad tiene ha sido influyente en el mundo de la arquitectura de software, pero ha
tenido un impacto limitado en tecnología de la información convencional. Entonces,
aunque este libro se concentrará en dos de estos puntos de vista, nos referiremos a ellos
como el punto de vista estructural y el punto de vista del comportamiento.
¡Los lectores exigentes deberían poder elaborar el mapeo entre terminologías!
1.4 ¿Qué hace un Arquitecto de Software?
El entorno en el que trabaja un arquitecto de software tiende a definir sus roles exactos y
responsabilidades. Se mantiene una buena descripción general del rol del arquitecto. por
el SEI en su sitio web. En lugar de resumir esto, describiré brevemente, en ningún orden
particular, cuatro habilidades esenciales para un arquitecto de software,
independientemente de su ambiente profesional.

 Enlace o Coordinador: los arquitectos desempeñan muchas funciones de enlace.

Actúan de enlace entre los clientes o clientes de la aplicación y el equipo técnico, a
menudo junto con el analista de negocios y requisitos. Sirven de enlace entre las
diversas ingenierías equipos en un proyecto, ya que la arquitectura es fundamental
para cada uno de ellos. Se relacionan con gestión, justificando diseños, decisiones
y costos. Se relacionan con las ventas fuerza, para ayudar a promover un sistema a
compradores o inversores potenciales. Mucho de tiempo, este enlace toma la
forma de simplemente traducir y explicar diferentes terminologías entre diferentes
partes interesadas.
 Ingeniero de software: excelentes habilidades de diseño son lo que consigue un
ingeniero de software al puesto de arquitecto. Son un requisito previo esencial
para el puesto. Más, Sin embargo, en general, los arquitectos deben promover las
buenas prácticas de ingeniería de software. Sus diseños deben documentarse y
comunicarse adecuadamente y sus los planes deben ser explícitos y justificados.
Deben entender la corriente abajo impacto de sus decisiones, trabajando
adecuadamente con las pruebas de la aplicación, equipos de documentación y
liberación.
 Conocimiento tecnológico: los arquitectos tienen un profundo conocimiento de la
tecnología dominios que son relevantes para los tipos de aplicaciones en las que
 trabajan. Ellos son influyentes en la evaluación y elección de componentes y
tecnologías de terceros. Realizan un seguimiento de los desarrollos tecnológicos y
comprenden cómo los nuevos estándares, Las propiedades y los productos podrían
ser aprovechados de manera útil en sus proyectos. Tan importante Los buenos
arquitectos saben lo que no saben y preguntan a otros con mayor experiencia
cuando necesitan información.
 Gestión de riesgos: los buenos arquitectos tienden a ser cautelosos. Están
constantemente enumerar y evaluar los riesgos asociados con el diseño y la
tecnología elecciones que hacen. Documentan y gestionan estos riesgos junto con
patrocinadores y gestión de proyectos. Desarrollan e instigan la mitigación de
riesgos estrategias y comunicarlas a los equipos de ingeniería pertinentes. Intentan
asegúrese de que no ocurran desastres inesperados.
Busque estas habilidades en los arquitectos con los que trabaja o contrata. Los arquitectos
juegan un papel central en el desarrollo de software, y debe ser polivalente en ingeniero
de software, tecnología, gestión y comunicaciones.
1.5 Arquitectura y Tecnologías
Los arquitectos deben tomar decisiones de diseño al principio del ciclo de vida de un
proyecto. Muchos de estos son difíciles, si no imposible, de validar y probar hasta que las
partes del sistema estén realmente construidas. La creación acertada de prototipos de
componentes arquitectónicos clave puede ayudar a aumentar la confianza en un enfoque
de diseño, pero a veces es difícil estar seguro del éxito de una elección de diseño
particular en un contexto de aplicación dado.
Debido a la dificultad de validar las primeras decisiones de diseño, los arquitectos confían
sensiblemente en enfoques probados y comprobados para resolver ciertas clases de
problemas. Este es uno de los grandes valores de los patrones arquitectónicos. Permiten a
los arquitectos reducir el riesgo al aprovechando diseños exitosos con atributos de
ingeniería conocidos. Los patrones son una representación abstracta de una arquitectura,
en el sentido de que se puede realizar en múltiples formas concretas. Por ejemplo,
publicar-suscribirse El patrón de arquitectura describe un mecanismo abstracto para
múltiples a-muchas comunicaciones entre editores de mensajes y suscriptores que desea
recibir mensajes. Sin embargo, no especifica cómo las publicaciones y sub- se gestionan
las suscripciones, qué protocolos de comunicación se utilizan, qué tipos de se pueden
enviar mensajes, etc. Todos estos se consideran detalles de implementación.
Desafortunadamente, a pesar de las opiniones equivocadas de una serie de ciencias de la
computación académicos, descripciones abstractas de arquitecturas que aún no se
ejecutan en computadoras, ya sea directamente o mediante una transformación rigurosa.
Hasta que lo hagan, la arquitectura abstracta Los ingenieros de software deben identificar
las tareas como implementaciones de software concretas. Afortunadamente, la industria
del software ha venido al rescate. Ampliamente utilizado Los patrones arquitectónicos son
compatibles con una variedad de marcos prediseñados disponibles. como tecnologías
comerciales y de código abierto. Por una cuestión de conveniencia, referiré a estos
colectivamente como tecnologías comerciales listas para usar (COTS), incluso aunque
estrictamente no es apropiado, ya que muchos productos de código abierto de muy alto
La calidad se puede utilizar libremente (a menudo con un modelo de pago por apoyo para
despliegue de aplicaciones). De todos modos, si un diseño requiere mensajes de
publicación-suscripción o un agente de mensajes, o una arquitectura de tres niveles,
entonces las opciones de tecnología disponible son muchas y variado de hecho. Este es un
ejemplo de tecnologías de software que proporcionan infraestructuras de software
independientes de la aplicación que implementan una arquitectura probada enfoques
culturales. Como se muestra en la Fig. 1.3, en la práctica se utilizan varias clases de
tecnologías COTS para proporcionar implementaciones empaquetadas de patrones
arquitectónicos para su uso en sistemas de IT (Tecnologías de la información). Dentro de
cada clase, existen productos comerciales y de código abierto que compiten entre sí.
Aunque estos productos son superficialmente similares, tendrán diferentes conjuntos de
características, implementados de manera diferente y tienen diferentes restricciones
sobre su uso.

Los arquitectos son bendecidos y maldecidos de alguna manera simultáneamente con esta
diversidad de la elección del producto. La competencia entre los proveedores de
productos impulsa la innovación, mejor conjuntos de funciones e implementaciones, y
precios más bajos, pero también supone una carga para el arquitecto para seleccionar un
producto que tenga atributos de calidad que satisfagan la aplicación requisitos. Todas las
aplicaciones son diferentes de alguna manera, y rara vez, si nunca, un producto de talla
única para todos. Diferentes implementaciones de tecnología COTS tienen diferentes
conjuntos de fortalezas y debilidades y costos, y en consecuencia se adaptará mejor a
algunos tipos de aplicaciones que a otros. La dificultad para los arquitectos está en
comprender estas fortalezas y debilidades. al principio del ciclo de desarrollo de un
proyecto y elegir una reificación adecuada de los patrones arquitectónicos que necesitan.
Desafortunadamente, esta no es una tarea fácil y los riesgos y costos asociados con la
selección de una tecnología inapropiada son altos. La historia de la industria del software
está plagada de malas elecciones y posteriores proyectos fallidos. Para citar a Eoin Woods,
y proporcionar otro extremadamente pragmática definición de arquitectura de software:
La arquitectura de software es el conjunto de decisiones de diseño que, si se toman
incorrectamente, pueden causar que el proyecto sea cancelado.
Los capítulos 4 a 6 proporcionan una descripción y un análisis detallados de estas
tecnologías.
1.6 Título de Arquitectura
Escanee los anuncios de trabajos. Verá arquitectos jefes, arquitectos de productos,
tecnología arquitectos técnicos, arquitectos de soluciones (quiero colocar un anuncio falso
para un problema arquitecto), arquitectos de empresas y, sin duda, varios otros. Aquí hay
un intento de dar algunas ideas generales sobre lo que significan:

 Arquitecto jefe: normalmente un puesto senior que gestiona un equipo de

arquitectos. dentro de una organización. Opera a un nivel amplio, a menudo
organizacional, y coordina los esfuerzos en todo el sistema, las aplicaciones y las
líneas de productos. Muy experimentado, con una rara combinación de profundo
conocimiento técnico y empresarial.
 Arquitecto de producto / técnico / de soluciones: normalmente alguien que ha
progresado a través de los rangos técnicos y supervisa el diseño arquitectónico
para un sistema o aplicación. Tienen un conocimiento profundo de cómo alguna
pieza de software realmente funciona.
 Arquitecto empresarial: por lo general, una función mucho menos técnica y más
centrada en el negocio. Los arquitectos empresariales utilizan varios métodos y
herramientas comerciales para comprender, documentar y planificar la estructura
de los principales sistemas de una empresa.
El contenido de este libro es relevante para los dos primeros puntos anteriores, que
requieren una sólida formación en informática. Sin embargo, los arquitectos
empresariales son algo diferentes bestias. Todo esto se vuelve muy confuso,
especialmente cuando eres un software arquitecto que trabaja en sistemas empresariales.
Esencialmente, los arquitectos empresariales crean documentos, hojas de ruta y modelos
que describir la organización lógica de las estrategias comerciales, métricas, capacidad
comercial, procesos comerciales, recursos de información, sistemas comerciales y redes
 infraestructura dentro de la empresa. Usan marcos para organizar todos estos
documentos y modelos, siendo los más populares TOGAF y el Marco Zachman. Ahora, si
soy sincero, lo anterior captura, prácticamente todo lo que sé sobre empresas
arquitectura, a pesar de haber estado involucrado durante un corto tiempo en un archivo
empresarial de infraestructura. Soy un friki de corazón y nunca he visto la necesidad de
una computadora, Conocimientos de ciencia e ingeniería de software, en arquitectura
empresarial. La mayoría de las empresas Los arquitectos premiados que conozco tienen
títulos en negocios o sistemas de información. Ellos son preocupados por cómo "alinear la
estrategia y la planificación de TI con el negocio de la empresa objetivos, desarrollar
políticas, estándares y directrices para la selección de TI "y" determinar
gobernanza de la mina”. Todas preocupaciones muy elevadas e importantes, y no
pretendo ser despectivo, pero estos no son mis intereses fundamentales. Las tareas de un
arquitecto empresarial ciertamente, no confíe en unas pocas décadas de informática
acumulada y teoría y práctica de la ingeniería de software. Si tiene curiosidad por la
arquitectura empresarial, hay algunas buenas referencias en al final de este capítulo.
Disfrutar.
1.7 Resumen
La arquitectura de software es una disciplina de diseño bastante bien definida y
comprendida. Sin embargo, solo porque sabemos lo que es y más o menos lo que hay que
hacer, este no significa que sea mecánico o fácil. Diseñar y evaluar una arquitectura para
un sistema complejo es un ejercicio creativo, que requiere un conocimiento considerable,
experiencia y disciplina. Las dificultades se ven agravadas por la naturaleza del ciclo de
vida temprano de gran parte del trabajo de un arquitecto. En mi opinión, la siguiente cita
de Philippe Krutchen resume a la perfección el papel de un arquitecto:
La vida de un arquitecto de software es una sucesión larga (y a veces dolorosa) de
subóptimas decisiones tomadas en parte en la oscuridad
El resto de este libro describirá métodos y técnicas que pueden ayudar para arrojar al
menos algo de luz sobre las decisiones de diseño arquitectónico. Mucha de esta luz
proviene de comprender y aprovechar los principios y tecnologías de diseño que han
demostrado funcionar en el pasado. Armado con este conocimiento, podrá abordar
problemas complejos de arquitectura con más confianza y, después de un tiempo, tal vez
incluso un poco de brillantez
1.8 El Resto solo son Citas