DOA Process in OutSystems: ODC vs O11
In any technology we must have a reliable architectural design process that is solid and, at the same time, iterative. The rapid evolution of technologies and business concepts leads to the need for high scalability and robustness, demonstrating and proving that the architectural design process occupies a very important position in the software development concept map.
The OutSystems platform early on adopted a process called DOA — Disclosure/Organize/Assemble. This process is the proposed basis for both the O11 and ODC versions, despite changing the focus on certain components of the three steps presented.
This article will cover the respective process steps in the O11 and ODC versions, as well as the differences and reasons for them.
We must take into account the differences in each of the versions, with the ODC leaving the intention of continuing where O11 took us. The existence of domain-oriented architecture is a concept that already appears in O11 but is much more enhanced by ODC. The fact of being Cloud Native (Kubernetes and Containers) instead of working on virtual machine instances (O11 Cloud) or bare metal (On Prem) and the fact of organizing code in applications and libraries instead of modules (sub-unit) and applications (unit) greatly simplify the visualization, understanding and implementation of domain-oriented architecture. For this reason, the basic concepts are similar, but the focuses of each of the DOA stages may appear slightly different.
Analyzing the DOA cycle in a generic way, it is clear that it is a process composed of three steps and that includes iteration. This must be repeated as many times as necessary to ensure that the architectural model is as correct as possible.
Analyzing each of the steps:
DISCLOSURE
From the point of view of the O11 version, this step has the purpose of discovering business concepts, integrations, UX/UI expectations and understanding application needs in general. It is normally at this step that we start writing User Stories, defining Roles and defining what the Information Architecture will be. Here we find the functional requirements and non-functional requirements of the solution.
The point of view in the ODC version follows the same line of reasoning, focusing heavily on the business component and highlighting the need to gain knowledge about it in order to ensure that the best possible decisions are made based on the outputs of all sessions, workshops and interviews.
ORGANIZE
In O11, the second step consists of distributing and organizing the concepts obtained and discovered in the first step by the Architecture Canvas, still in a high-level way. Distributing the concepts across their layers (considering the three layers of the Architecture Canvas) and separated by life cycles will allow us to have a more concrete vision of the type of approach we should follow and which concepts should be aggregated or segregated. The fact that the design cycle is iterated often means that concepts that are justified remain segregated in a given iteration and are subsequently aggregated (and vice versa).
When it comes to ODC, we have one big difference: the Architecture Canvas. The entire theory behind this step is identical, but we no longer have 3 layers of the Architecture Canvas to carry out the distribution. In this case, and taking into account the strong connotation of domains in ODC, we must guide the organization of concepts by the domains themselves. We must group strongly related concepts (bounded contexts) through the grouping of business concepts. In order to identify these same bouded contexts, we must ask the following questions:
- What are the limits of each business domain and its experts?
- What are the associated business processes, ownership, sponsorship and data flows?
- Is there a great dependence between each of the domains, or a risk of loss of cohesion or clustering caused by this same dependence?
We must avoid as much as possible many references between domains, and if they exist in great quantity, they probably demonstrate that the architectural model must be revised.
Furthermore, the use of a common language must be guaranteed among everyone involved for greater understanding of the architectural model and all its components.
In general, well-defined ownership and sponsorship must be guaranteed, in which each application must only have one owner and one sponsor (although it may be possible for an owner or sponsor to be associated with more than one application) and we must be sure that there is team independence.
In the ODC version, the need to iterate between the Disclosure and Organize steps is sometimes mentioned, as many times as necessary before introducing the Assemble step. This way, the next step is simpler to understand and execute.
ASSEMBLE
In O11, the objective of the last step is to map the concepts organized in the previous step and make them correspond with known architectural patterns, using the types of modules foreseen in the Architecture Canvas implementation. This does not mean that there is no specificity and cases that differ from what was expected, but the fact that we follow the known rules and standards will guarantee greater cohesion and robustness of our architectural model. The reference to standards goes from the concept of layers, sub-layers and agreed suffixes to pre-defined design integration standards.
For the ODC version, it is a process much more related to the domain (the fact of mapping concepts and domains directly into applications allows us to strengthen the connection with owners and sponsors).
You must start by mapping the respective business sponsors and business owners to the identified bounded contexts, always taking into account the organization’s organizational chart and the information collected. This will allow the pieces of architecture to be assembled in a more evident and comprehensive way.
One should always try to achieve the best domain definition and grouping, allowing the best trade off between cohesion and loose coupling. This results in scalability, robustness, reduction of unnecessary complexity and reduction of development time. Furthermore, the objective is to obtain maximum independence in the development lifecycle.
IN SUMMARY
A more careful analysis reflects greater simplicity and adaptation of the ODC version to the implementation of domain-oriented architectural models, and there is a more direct relationship between the architectural artefacts of this version with the artefacts and domains than in the O11 version. It is easy to see that the ODC focuses more on common understanding between everyone and correctly isolated lines of business than on the technical component itself (the relationship between domains and applications/libraries facilitates this approach).
This does not mean that O11 is a wrong approach (because we may not have a domain-oriented architecture, at least not yet), but it allows us to see that, in a way, the evolutionary steps taken are of continuity and show that if you are in the right way.
To learn more about the DOA process in OutSystems O11:
To learn more about the DOA process in OutSystems ODC:
As always, I hope this article helps someone on their OutSystems journey.
