Las arquitecturas y los patrones de referencia son modelos reutilizables que capturan las mejores prácticas y estándares para resolver problemas comunes o recurrentes en un dominio o contexto específico. Proporcionan una visión general de alto nivel de los elementos clave, las relaciones, los principios y las directrices que definen una solución. También ofrecen ejemplos, plantillas y artefactos que se pueden adaptar y personalizar para escenarios específicos. Las arquitecturas y los patrones de referencia se pueden encontrar en varios orígenes, como marcos de la industria, catálogos de proveedores, repositorios de la comunidad o repositorios internos.
An example in wireless products space would be modem suppliers who sell SoC (System on Chip) products and demonstrate performance and use cases using reference architectures which System Integrators and OEMs can use in their end products.
Bringing examples from non-software world can be useful. I myself struggled to appreciate the reference architecture for sometime. Hotel industries. Think of core components of a 500 rooms 5 star hotel. You want to build and operate a 5 star hotel but you are not sure whether you will be successful. To reduce risk and to learn the game, think of a 100 room 3 star hotel with a provision to upgrade it to 5 star and then expand from 100 rooms to 500 rooms. That mental model is a reference architecture. Nowhere you will be thinking of naming the hotel or the front view (Architectural) of how it will look when finished.
In my experience a reference architecture is foundational and serves as input to solution architecture deliverables. It validates 'what is' while the solution architecture prescribes 'what will be'.
RA - it's an architecture for the solution that would solve a business problem within a specific domain. E.g. In insurance industry we might find a reference architecture on how to implement a solution that solve the problem of migrating business rules from a legacy solution to a modern solution. Pattern, would define how components would fit together to solve a specific problem and it's not necessarily in an industry view, but from more abstracted technology view e.g. How to implement a lot of business rules for example and this might be leveraging something like Oracle Business Rules engine. Now Reference architecture would add a bit of technology to fit in a landscape and scale of organisation will influence the scope of documents
Las arquitecturas y los patrones de referencia pueden ayudarle a usar arquitecturas y patrones de referencia para guiar y reutilizar el diseño de la solución de varias maneras. En primer lugar, pueden ayudarle a comprender mejor el dominio del problema y el espacio de solución al proporcionar un vocabulario, una estructura y una lógica comunes. En segundo lugar, pueden ayudarlo a acelerar el proceso de diseño al reducir la necesidad de reinventar la rueda y proporcionar soluciones probadas y comprobadas. En tercer lugar, pueden ayudarte a mejorar la calidad y la coherencia del diseño al garantizar la alineación con las mejores prácticas y estándares del dominio o contexto. En cuarto lugar, pueden ayudarlo a comunicarse y colaborar con las partes interesadas de manera más efectiva al proporcionar una visión clara y compartida de la solución.
Referencing reusable blocks in alignment with industry will ensure the quality of produced artefacts (designs) and make sure that all components are addressed from regulations, security, -eilities, etc. Those reusable building blocks can be reference architectures or patterns. Moreover, it helps Architects to leverage what has been already produced and let them globally and collectively build solutions that fit-for-purpose and fit-for-use. However, this is influenced by the scale of organisation, how collaborative is this organisation, how the company is rigid vs open for innovation. Moreover, relying on reusable building blocks will massively increase ROI ensuring a comprisable value
Para utilizar arquitecturas y patrones de referencia de forma eficaz, debe seguir algunos pasos. En primer lugar, debe identificar y seleccionar las arquitecturas y los patrones de referencia relevantes para el dominio y el contexto del problema. Puede hacerlo investigando las fuentes disponibles, evaluando la idoneidad y credibilidad de los modelos y comparando los beneficios y las ventajas y desventajas de las diferentes opciones. En segundo lugar, debe analizar y adaptar las arquitecturas y los patrones de referencia para sus requisitos y restricciones específicos. Para ello, asigne los elementos, las relaciones, los principios y las directrices de los modelos al alcance, los objetivos y los criterios del proyecto, y modifique o amplíe los modelos según sea necesario. En tercer lugar, debe aplicar e implementar las arquitecturas y los patrones de referencia para el diseño de la solución. Para ello, utilice los ejemplos, las plantillas y los artefactos de los modelos como entradas, salidas o bloques de creación para el diseño, y siga las prácticas recomendadas y los estándares de los modelos a lo largo del ciclo de vida del diseño.
As business capability modelling matures in enterprise architecture it provides an opportunity to link reference architectures to capabilities rather than technology or domain specific models. This provides a greater understanding with business stakeholders and increased business alignment. It enables the creation the creation of the ref architectures to be prioritised in line with the strategic capabilities and promotes re-use across the enterprise. For example a RA for CRM would be linked to capabilities for customer data management, Marketing Automation, Lead Management etc... These capability will be a common requirement across multiple workstreams and domains and can therefore easily identify and subscribe to the RA.
Before thinking on how to re-use, we should think on how those deliverables are discoverable and consumable and this means they are flagged with all the required metadata that set their context on how, when to use and how this will contribute to solve domain problems. Once there is a clarity on the above, it will be easy for architects to match the RAs with their needs and use what makes more sense, closer to their problem and probably they might inherit it or create new versions that fit more on their needs.
Hay muchos ejemplos de arquitecturas y patrones de referencia para diferentes dominios y contextos. Por ejemplo, en el dominio de la nube, puede encontrar arquitecturas y patrones de referencia para varios modelos de servicios en la nube, como la infraestructura como servicio (IaaS), plataforma como servicio (Paas)o software como servicio (SaaS)y para diversos escenarios en la nube, como la migración, la seguridad, la escalabilidad o la resiliencia. En el dominio del software, puede encontrar arquitecturas y patrones de referencia para varias arquitecturas de software, como microservicios, sin servidor o controladas por eventos, y para varios escenarios de software, como integración, rendimiento o pruebas. En el dominio de datos, puede encontrar arquitecturas y patrones de referencia para varias arquitecturas de datos, como el lago de datos, el almacenamiento de datos o la canalización de datos, y para varios escenarios de datos, como análisis, gobernanza o calidad.
A lot of times a reference architecture is just the starting point. I'd go a step further and call out the need for multiple reference implementations.
Las arquitecturas y los patrones de referencia no son balas de plata que puedan resolver todos los problemas de arquitectura de soluciones. Tienen algunos desafíos y limitaciones que debe conocer y abordar. En primer lugar, las arquitecturas y los patrones de referencia no son soluciones únicas que puedan adaptarse a cualquier dominio o contexto problemático. Se basan en suposiciones, compensaciones y compromisos que pueden no coincidir con sus requisitos y limitaciones específicos. En segundo lugar, las arquitecturas y los patrones de referencia no son soluciones estáticas o definitivas que puedan permanecer inalterables a lo largo del tiempo. Están sujetos a cambios y actualizaciones debido a la evolución de las tecnologías, normas y prácticas que pueden afectar a su validez y aplicabilidad. En tercer lugar, las arquitecturas y los patrones de referencia no son soluciones autoexplicativas o autoimplementables que puedan utilizarse sin un análisis y una adaptación adecuados. Requieren interpretación, personalización e integración con otros modelos y componentes que pueden implicar complejidad y ambigüedad.
One point I would like to highlight under this section is while reference architectures can be very useful tool - There is a common pitfall that it suffers from - for many they become limiting factors and if not used correctly, can adversely affect the cause. Reference architectures are what it says on the tin - reference materials. They might be a good place to start, but they should never limit an architect's blue sky thinking, or an architect's deep understanding of the specific business vertical or product domain. They should never be used as a stencil or as a shortcut to creating an architecture.
Don't trap yourself in box thinking. It is critical that the architect not create structural limitations to the problem they are currently trying to solve by referencing prior solutions. The fundamentals of good Architecture are found in innovation and creativity. Of course, not every problem needs a Michael Angelo masterpiece. Some problems just don't need to be solved. It is self awareness and self acceptance that allows an Architect to balance their individual perspective with what others have done before to achieve a solution that addresses the current problem domain before them.
I am often required to create a reference architecture at the beginning of every engagement, simply to level-set with all stakeholders. Often it doesn't exist and eats into the requirement elicitation phase. The process is iterative in nature, requiring identifying & defining the architecture landscape (including boundaries). It serves as the blueprint and register for all solution related additions and modifications and requires a skilled hand to deliver quality output.
Be selective about the reference architectures and patterns that you use. Not all reference architectures and patterns are created equal. Some are more well-defined and well-documented than others. Use reference architectures and patterns as a starting point, not a finished product. Reference architectures and patterns are a valuable tool, but they are not a substitute for careful planning and design. By following these tips, you can use reference architectures and patterns to guide and reuse solution design in a way that is effective, efficient, and sustainable.
A famous Musk quote .... "engineers are trained to solve problems. They are just not trained to pick the ones that just don't need solving." Each solution should start with an assessment of priorities. The lower ones can lean heavily on reference architecture. The higher ones need a little more work. Reference architectures should be another tool in the bag but it's not silver.
Like traditional architecture, one must refer to the blueprint of an existing structure before any attempt to change it. A reference architecture is a blueprint, and must behave the same.