Continuando con OpenUP

  "Somos arquitectos de nuestro propio destino."

Albert Einstein

 Esa si es una frase más filosófica, es cierto nos preocupa la arquitectura del sistema, se leen y repiten patrones, a veces de manera mecánica así si ese arquitectura centrada en los datos a no es de capas, y el proyecto más importante que es la vida, en ese no se aterrizan los conceptos, te cambian el contexto y la cosa ya empieza a tambalear. Uh  cásate con tu arquitectura de prisa y arrepiéntete en tu tiempo libre [Barry boehm]

El considerar diferentes alternativas arquitectónicas en una etapa en la que hacer cambios al diseño todavía es relativamente fácil, claro se nos pasa el tiempo y después los controles de cambio son súper costosos, uh pero para la vida humana a veces no es tan fácil hay que desaprender para poder realmente dar un nuevo paso, el ego humano no permite quitar el componente “mi”.

Bueno pero como el titulo lo indica, quiero dejar otros conceptos que desarrolla OpenUp, disponibles en su sitio:

Sin un fundamento arquitectónico, un sistema evolucionará en una forma ineficiente y casual. Tal sistema frecuentemente presenta dificultades para evolucionar, reutilizarse o integrarse sin una reconstrucción sustancial. Esto también dificulta organizar el equipo o comunicar las ideas sin el enfoque técnico común que la arquitectura proporciona.

Cree la arquitectura para lo que usted conoce hoy

Como Albert Einstein dijo, haga cada cosa tan simple como sea posible pero no más simple. Los proyectos de software tienen recursos restringidos, y el deseo de los desarrolladores por crear soluciones elegantes podría llevar a un sistema de mayor complejidad de la que los stakeholders solicitan. Los esfuerzos de corregir en un futuro un sistema en un ambiente turbulento o incierto probablemente conducirán a un código sobrecargado, mientras se aumentan los sobrecostos con poco beneficio real que mostrar por esto.

Cree arquitecturas que se orienten a las necesidades reales de los stakeholders y provean la flexibilidad apropiada y apresúrese por los requisitos como se conocen hoy. Evite el deseo, sin importar que tan bien intencionado sea, de especular sobre requisitos futuros y por eso sobre dimensionar la arquitectura: si usted tiene la habilidad para hacer la arquitectura de algo hoy, entonces claramente usted podrá también tener la habilidad de hacer esta arquitectura mañana cuando usted realmente necesite hacerla.

Sobrelleve la complejidad elevando el nivel de abstracción

El software es complejo, y las personas tienen una capacidad limitada para sobrellevar la complejidad. A medida que un sistema se hace grande, empieza a ser difícil para el equipo desarrollar una comprensión común del sistema, porque es difícil ver todo el panorama completo.

Por consiguiente, use modelos que eleven el nivel de abstracción enfocándose en problemas importantes de alto nivel, tales como relaciones y patrones, en lugar de sumergirse en los detalles. Modelar realza el nivel de abstracción y permite al sistema ser más fácil de entender desde diferentes perspectivas.

Permita al problema dirigir la solución

La arquitectura podría empezar a ser difícil de mantener y adaptar a las nuevas necesidades de los stakeholders cuando la tecnología, en lugar del problema, dirige la solución

Permita que las necesidades de los stakeholders guíen la arquitectura. 

Organice la arquitectura con bajo acoplamiento, componentes altamente cohesionados

Un alto acoplamiento entre componentes hace un sistema frágil y difícil de entender. El software es costoso de crear, de modo que si existen componentes que pueden ser reutilizados, estos pueden reducir el esfuerzo requerido para crear el sistema.

Organice la arquitectura del sistema en los componentes que maximizan la cohesión y minimizan el acoplamiento. Esto mejora la comprensión, incrementa la flexibilidad e incrementa las oportunidades de reutilización.

Reutilice recursos existentes

Es malgastador construir lo que usted puede simplemente reutilizar, descargar o aún comprar.

Por consiguiente, haga cada esfuerzo para reutilizar recursos existentes. Los desarrolladores son frecuentemente renuentes a reutilizar recursos, porque estos recursos no se ajustan exactamente a sus necesidades o esos recursos tienen poca calidad. Este preparado para balancear el ahorro que usted puede realizar usando un recurso existente, aún si el recurso requiere cambiar la arquitectura o suavizar una restricción.

Apalanque la arquitectura como una herramienta colaborativa

La falta de un entendimiento común de los desarrolladores acerca de un sistema, conduce a la indecisión y a opiniones contrarias entre los desarrolladores y se puede paralizar el proyecto rápidamente. Los desarrolladores pueden tener diferentes modelos mentales del sistema y trabajar propósitos cruzados el uno del otro.

Cómo  también me identifico con otra frases de Einstein "Un estómago vacío, es un mal consejero." Así que voy a comer alguito, hasta la siguiente entrada