The ODC Design Process: Shaping Tomorrow's Cloud-Native Applications

Hey everyone, André here! As someone deeply passionate about low-code development and cloud-native architecture, I wanted to share some insights on how the design process in OutSystems Developer Cloud (ODC) is changing the game. Whether you're just getting started with ODC or already building in it, this shift in mindset is something we need to talk about. Let's dive in!

The Mindset Shift: From Traditional to Cloud-Native Design

When I started working with ODC, I quickly realized that it wasn't just another iteration of OutSystems: it was a whole new way of thinking about application design. Traditional monolithic approaches don't work anymore. Instead of a single, tangled application, we need to design with autonomy and scalability in mind.

Applications should be composed of independent services that can evolve separately and react dynamically to change, rather than executing rigid, pre-defined processes. Above all, they must be built for elastic scalability, using cloud-native infrastructure to handle growing demands.

To thrive in this new model, we have to design differently. Here’s what I’ve learned:

• Applications should be built independently.

• We must assume failures will happen and design with redundancy in mind (resilience).

• Monitoring and logging should be part of the design, not an afterthought (observable).

• ODC provides built-in security mechanisms, but we must use them correctly (secure by default).

The Design Process

It uses the Domain-Oriented Architecture (DOA) that already exists in O11 but is greatly enhanced by ODC.

It's a design process that focuses on three key steps - Disclose, Organize, and Assemble, to help you design your architecture.

Its purpose is to define the architectural blueprint of your application based on the business domain and business goals, ensuring an organized, scalable, and maintainable structure.

DOA is a model that organizes software systems into independent business domains.

Key Steps in the ODC Design Process

Disclose: The purpose of this step is to discover the business concepts and goals, starting with stakeholder interviews to elicit business needs through a few key questions:

• What are the business concepts?

• Who are the business owners and sponsors, and how do we organize the business relationships?

• What are the system integrations that we need?

• What are the NFRs?

 Then we need to follow the next approaches:

The purpose of this step is to discover concepts, integration needs, and UX expectations and to understand the application needs. It is usually in this step that we start writing user stories with the main cases, define roles and define what the information architecture will be. Here, we find the functional and non-functional requirements of the solution.

At the end of the disclosure, we take all that we have identified and put it on a blank board to get a broad visual of the global concepts.

1- ORGANIZE:

The second step is to join strongly related concepts (bounded contexts) by grouping business concepts based on the following:

• We must avoid references between domains and the boundaries that define who is responsible for what within the system.

• We must ensure well-defined sponsorship and ownership, each application must have only one owner and sponsor (although it may be possible for an owner or sponsor to be associated with more than one application), and we must ensure team.

• The dependency between business concepts helps you organize them on clusters and the cohesion between concepts.

• The use of a common language in the design of applications that everyone needs to understand.

Well-defined sponsorship and ownership must be ensured, each application must have only one owner and sponsor (although it may be possible for an owner or sponsor to be associated with more than one application), and we must ensure team independence.

We need to iterate between the Disclose and Organize steps as many times as necessary before introducing the next step to retrieve more information and concepts about the domains.

2 - ASSEMBLE:

In the last step we should aim for the independence of the teams, release cycles autonomy while keeping a clear ownership and a complexity manageable, we will try to map the clusters/groups of concepts made on the last step to ODC Applications and Libraries, and we are also going to tie all with our teams, organization, and business:

• Understand the business (who are the business sponsors, owners, and teams associated with the applications).

• Define who is responsible for each part of the system. This helps avoid confusion, improves collaboration between teams, and ensures that each domain has a well-defined owner.

• Achieve maximum independence in the development lifecycle.

• We don't want to overburden our teams, so it's better to reduce complexity to avoid delays and overload.

Before finalizing your architecture design, it is critical to understand how the organization's structure affects your strategy. Adhering to best practices will help avoid overlapping responsibilities and ensure clear ownership.

Establishing clear ownership is essential for smooth application development. This avoids conflicting requests for the same business context from multiple stakeholders within the same application.

Clear ownership means having a single point of accountability for each business context: the business owner.

It is recommended to start with a simple approach. As the business evolves, iterate and add complexity only when necessary.

3 - PREVENT MIXING BUSINESS OWNERS:

In scenario 3, for example, if you have two owners for the finance application, it might generate ineffective execution due to the

• Unclear ownership and accountability.

• Risks, collisions, and conflicting priorities caused by simultaneous work.

As a best practice, avoid the downsides of having two simultaneous owners for an application. If necessary, split finance into two different applications, as in Scenario 4.

To ensure independent release cycles, business sponsors play a critical role in the organization.

Since business sponsors are typically responsible for the budget, they have the authority to prioritize requirements. Because different sponsors may require different rates of change, it is important to align your architecture with the organizational structure. This approach helps maintain independent release cycles.

Start with a simple strategy and introduce complexity incrementally, only as needed.

4 - PREVENT MIXING BUSINESS SPONSORS

In this scenario, if we had two sponsors for the finance application, we could run into problems because if each sponsor's requirements change at the same time, it could lead to conflicting priorities. So, the best practice is to avoid this scenario.

To ensure that business sponsors can request changes at different speeds, create two apps: one for Finance and one for Human Resources.

Always aim for the independence of teams.

Now that you understand the basic best practices for maintaining a smooth development flow and release cycle, you can start building your architecture.

Start by mapping your business owners and sponsors to their respective bounded contexts, taking into account the structure of the organization and the insights you have gathered from your stakeholders. With this approach, you can design your architecture more effectively by applying best practices.

The goal is to strike the right balance between cohesion and loose coupling. This allows developers to minimize effort and architectural complexity while ensuring independence in the development lifecycle across applications and teams.

In the end, our final architecture diagram will look something like this example:

ODC is Not Just a Platform—It’s a Mindset!

Ultimately, ODC is not just a set of tools, it's a new way of thinking. I've seen firsthand the impact of this approach on real projects:

✅ Faster deployment cycles: Code gets into production much faster, thanks to built-in CI/CD.

✅ Improved performance: Applications scale dynamically without performance bottlenecks.

✅ Stronger security: Native Zero Trust security provides robust protection.

✅ Lower maintenance effort: A modular, microservices-based approach makes updates painless.

If you're still building applications with a monolithic mindset, I challenge you to rethink and embrace the cloud-native way.