wichat_es4a

Describe las necesidades importantes y las fuerzas mayores que los arquitectos del software y el equipo de desarrollo deben considerar Esto incluye

Cualquier requisito que limite la libertad de los arquitectos de software en sus decisiones de diseño e implementación, o en decisiones sobre el proceso de desarrollo. Estas restricciones a veces van más allá de los sistemas individuales y son aplicables a organizaciones y empresas enteras.

Los arquitectos deben saber exactamente dónde tienen libertad en sus decisiones de diseño y dónde deben adherirse a restricciones. Las restricciones siempre deben ser consideradas; sin embargo, pueden ser negociables.

Tablas simples de restricciones con explicaciones. Si es necesario, puedes subdividirlas en: Restricciones técnicas, Restricciones organizativas y políticas, y convenciones (por ejemplo, guías de programación o versionado, documentación o convenciones de nomenclatura).

Consulta Architecture Constraints en la documentación de arc42.

El ámbito y contexto del sistema, como su nombre lo indica, delimita el sistema (es decir, su ámbito) de todos sus interlocutores (sistemas y usuarios vecinos, es decir, el contexto del sistema). De este modo, especifica las interfaces externas.

Si es necesario, diferencie el contexto empresarial (entradas y salidas específicas del dominio) del contexto técnico (canales, protocolos, hardware)..

Las interfaces de dominio y las interfaces técnicas con los socios de comunicación se encuentran entre los aspectos más críticos de su sistema. Asegúrese de comprenderlas por completo.

Varias opciones:

Vea Context and Scope en la documentación arc42.

A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes

These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules.

Keep the explanations of such key decisions short.

Motivate what was decided and why it was decided that way, based upon problem statement, quality goals and key constraints. Refer to details in the following sections.

See Solution Strategy in the arc42 documentation.

The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes, interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations, data structures, …​) as well as their dependencies (relationships, associations, …​)

This view is mandatory for every architecture documentation. In analogy to a house this is the floor plan.

Maintain an overview of your source code by making its structure understandable through abstraction.

This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details.

The building block view is a hierarchical collection of black boxes and white boxes (see figure below) and their descriptions.

Level 1 is the white box description of the overall system together with black box descriptions of all contained building blocks.

Level 2 zooms into some building blocks of level 1. Thus it contains the white box description of selected building blocks of level 1, together with black box descriptions of their internal building blocks.

Level 3 zooms into selected building blocks of level 2, and so on.

See Building Block View in the arc42 documentation.

The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas:

Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their architectural relevance. It is not important to describe a large number of scenarios. You should rather document a representative selection.

You should understand how (instances of) building blocks of your system perform their job and communicate at runtime. You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view).

There are many notations for describing scenarios, e.g.

See Runtime View in the arc42 documentation.

The deployment view describes:

Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments.

Especially document a deployment view if your software is executed as distributed system with more than one computer, processor, server or container or when you design and construct your own hardware processors and chips.

From a software perspective it is sufficient to capture only those elements of an infrastructure that are needed to show a deployment of your building blocks. Hardware architects can go beyond that and describe an infrastructure to any level of detail they need to capture.

Software does not run without hardware. This underlying infrastructure can and will influence a system and/or some cross-cutting concepts. Therefore, there is a need to know the infrastructure.

Maybe a highest level deployment diagram is already contained in section 3.2. as technical context with your own infrastructure as ONE black box. In this section one can zoom into this black box using additional deployment diagrams:

See Deployment View in the arc42 documentation.

This section describes overall, principal regulations and solution ideas that are relevant in multiple parts (= cross-cutting) of your system. Such concepts are often related to multiple building blocks. They can include many different topics, such as

Concepts form the basis for conceptual integrity (consistency, homogeneity) of the architecture. Thus, they are an important contribution to achieve inner qualities of your system.

Some of these concepts cannot be assigned to individual building blocks, e.g. security or safety.

The form can be varied:

A potential (but not mandatory) structure for this section could be:

Note: it might be difficult to assign individual concepts to one specific topic on this list.

See Concepts in the arc42 documentation.

Important, expensive, large scale or risky architecture decisions including rationales. With "decisions" we mean selecting one alternative based on given criteria.

Please use your judgement to decide whether an architectural decision should be documented here in this central section or whether you better document it locally (e.g. within the white box template of one building block).

Avoid redundancy. Refer to section 4, where you already captured the most important decisions of your architecture.

Stakeholders of your system should be able to comprehend and retrace your decisions.

Various options:

See Architecture Decisions in the arc42 documentation. There you will find links and examples about ADR.

This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals)

Here you can also capture quality requirements with lesser priority, which will not create high risks when they are not fully achieved.

Since quality requirements will have a lot of influence on architectural decisions you should know for every stakeholder what is really important to them, concrete and measurable.

See Quality Requirements in the arc42 documentation.

A list of identified technical risks or technical debts, ordered by priority

“Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.)

This should be your motto for systematic detection and evaluation of risks and technical debts in the architecture, which will be needed by management stakeholders (e.g. project managers, product owners) as part of the overall risk analysis and measurement planning.

List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts.

See Risks and Technical Debt in the arc42 documentation.

The most important domain and technical terms that your stakeholders use when discussing the system.

You can also see the glossary as source for translations if you work in multi-language teams.

You should clearly define your terms, so that all stakeholders

A table with columns <Term> and <Definition>.

Potentially more columns in case you need translations.

See Glossary in the arc42 documentation.