�ݺ�ߣ

Editor's Notes

• #1: In this session, we will explore the foundational concepts of architecture and the step-by-step process of designing effective architectures.
• #2: Web apps are responsive applications designed to work seamlessly across all browsers and devices. They are categorized into three types: web apps, tablet apps, and phone apps.
• #3: You can define timers to execute logic in the background. At the Interface level, Screens, Blocks and other UI related elements enable you to build user interfaces. Regarding logic, you can create elements such as Client Actions, Server Actions, Service Actions, and Integrations,��you can also create Roles and handle Exeptions. Regarding data, you can create regular Entities and static Entities, as well as other data-related elements such as Client Variables and Settings.
• #4: When you think of Libraries, the first important thing you need to consider is their purpose. A Library is an app that other web apps or libraries reuse so they can have highly-reusable elements such as Blocks, Client and Server Actions, consume REST services, Static Entities, and Settings. There is one important thing about Static Entities... When we create static Entities inside Library, Static Entities are not mapped to an actual database table; instead, they act more like a real enumerator. It means the values that we define at design time, are part of the application's metadata, it will not stored in a physical table. But when we create static Entities��inside a Web app, a database table is created as normal. Despite this difference, they work the same way from the point of view of a Developer working in ODC Studio.
• #5: If you think of a library as an asset that provides business agnostic functionality, it's easy to understand that a library isn't meant to be used directly by external users or systems. Therefore, the elements that can be created inside a library are meant to be highly reusable by apps and other libraries.
• #6: Now, let's learn how these elements can be reused across web apps and libraries.
• #7: Libraries can consume other Libraries, and these dependencies are�� "strong dependencies," �� Although Libraries can not expose a REST service, they can consume RESTful services from an external system. This feature allows you to create connectors to external systems, which in reality are weak dependencies— hence we can see the dashed line. an app can expose Screens, Entities, Service Actions, Static Entities, and Structures to be consumed by another app. Consuming one of these elements from one App to another creates a weak reference. Entities are always exposed in read-only mode. Regarding integrations, Web Apps can consume a REST service and also expose REST services to external systems. Another important observation here is that although you can create Server Actions inside an App, you cannot make them Public. To expose logic to another app, you need to use Service Actions. Note: that a Library cannot consume any of these elements from an app.
• #8: We will explore the three key steps of the design process: disclose, organize, and assemble. Before diving into the design process itself, we’ll begin by discussing how to get started and gather the necessary non-functional requirements. Next, we’ll take a closer look at each step in detail and share some recommended best practices. Finally, we’ll conclude with an example of an architecture blueprint.
• #9: The architecture design process is divided into three steps: Disclose, Organize, and Assemble. In the Disclose step, we identify all business concepts and non-functional requirements (NFRs). During the Organize step, the focus is on grouping these concepts into bounded contexts based on specific criteria, ensuring the optimal level of granularity. Finally, the Assemble step involves mapping the bounded contexts to ODC applications by adhering to best practices that emphasize clear ownership and independent development life cycles for different teams.
• #10: To prepare for the Disclose step, it’s crucial to conduct in-depth interviews with stakeholders to gather all necessary information. During these discussions, consider asking the following key questions: What are the business concepts relevant to our use case? What is the organizational structure? Who are the business owners and sponsors? How do these stakeholders relate to the different business contexts? How can we ensure that teams can work independently and maintain a steady delivery pace? Finally, what are our non-functional requirements, reusable components, and external system integrations? These questions will guide us in identifying business concepts, grouping them into bounded contexts, and mapping them to the organization’s structure, including the associated business sponsors, owners, and teams.
• #11: To drill down and detail further the Non Functional Requirements, we have some que sample questions that can be used during the interviews to the stakeholders. These questions enable us cover more ground, making sure all important topics are disclosed during the interview process. The sample questions should be complemented as needed with others that might make sense in each context.
• #12: After the interviews with the stakeholders, we now can start to disclose the application concepts.
• #13: We should start with the business requirements, processes, user stories, personas, and roles. The information architecture will also help identify more business concepts. Integrations and non-functional requirements are also important, as they define the architecture's more in-depth concepts. Finally, end-users' expectations are also important; you should therefore taken them into consideration. As we go, we also need to gain some level of business knowledge, to ensure better design decisions ahead.
• #14: The application concepts can be of several types, such as personas, roles, business concepts or NFRs.
• #15: Concepts should be listed and described so that everyone involved in the design and development process has a clear understanding of what each concept means or stands for. Some concepts can be easier to grasp like Customer, which can be a persona or role, and Claims or Quotes, which are business concepts. Other may require further detailing, like the integration needs.
• #16: After discovering and identifying all the application concepts through the disclose process, we can represent them as a visual cloud of concepts, with no specific order or grouping at this point. Here's the complete list of concepts from our example represented in such a cloud of concepts.
• #17: Next step is Organize.
• #18: In the Organize step, we'll focus on relations and boundaries between concepts to group these concepts into bounded contexts. These bounded contexts do not only group related business concepts, but also take into consideration other aspects. By identifying the domain expert boundaries, you'll get an idea of how the business ownership is defined. Getting to know the business processes, data flows and ownerships will provide greater details about the stakeholders. The dependencies between business concepts will help organize them into clusters, promoting a cohesion between concepts. Finally, a common understanding of the language is also highly important to ensure that everyone is on the same page. Remember, you might need multiple iterations between the Disclose and Organize steps.
• #19: By applying the previous guidelines to group the concepts into bounded contexts, we will end up with several groups like the ones in the illustration. We have concepts like the Payment, Guidewire and Ledger in the Billing group, and also the Home Insurance concepts which does not group with any other and is in its own bounded context. Following that, we also identify the integrations with external systems, as we can see with the SAP and Guidwire, and also the reusable components. At this point we have our bounded contexts, well identified, but we can always re-iterate the process.
• #20: Final step is Assemble.
• #21: This is the step where we will map the bounded contexts into ODC applications, while promoting independence between the development teams, autonomy in release cycles and clear ownership of these apps. To achieve that, there are some important guidelines. The way teams, business owners, and business sponsors are organized will be of utmost importance. Knowing this structure will help you establish a clear ownership of the concepts at hand. Different concepts may have different release cycles. It's important to have a clear notion of these differences, so you can assemble concepts properly, and ensure release cycle independence between different teams. Make sure you start with a low-complexity solution. This will help you lower the cognitive load, making it easier to understand. Let’s see what are the best practices, that we can use to mitigate these impacts.
• #22: The most simple scenario is where a business owner owns a single app. However, a business owner may also own multiple apps, which is also fine, since there is a clear ownership. But, for instance, having two owners for the claims and billing application is problematic and would lead to ineffective execution. Why is that? Well, because this would lear do unclear responsibility and accountability, as well as risks, collisions and conflicting priorities caused by concurrent work. So, we should avoid this scenario. While assembling concepts, it is critical to keep the business owners in mind. Actually, a good approach to assemble concepts into apps is based on business owners, since they are the go to persons for each business context. This leads to scenario number four, with the Claims and Billing being split into two different applications. Now, each business owner has its own app, and apps may depend on each other.
• #23: Business sponsors also play a key role in organizations. As they are usually accountable for the budget, they will have the power to prioritize on demand. This may lead to different sponsors requiring different paces. And that is why it's so important to match our architecture to the organizational structure. Not mixing business sponsors will benefit lifecycle independence. A scenario with one sponsor, one business owner, and one app is as simple as it gets. It is also acceptable if we have two sponsors and only one business owner, as long as each sponsor matches its own application, like Claims and Customer Portal. We would be able to cope with a different pace of change in each app. Now, when we have multiple business sponsors for the same application, with one or two business owners, things get tricky. If the sponsors start requesting changes at the same time, we can easily end up with conflicting priorities, impacting the apps' release cycle. So, as a best practice, we should avoid this scenario. The correct approach in such situations would be to split the apps in two, with each app having its business sponsor and business owner, thus resulting in scenario 4. By following this best practice, it will be easy to ensure our development teams have independent release cycles. It also enables us to make the most out of OutSystems Developer Cloud, and scale it to many teams working on big portfolios of applications and libraries.
• #24: Regarding team ownership, each app should have only a single product team. If we only have one team, one owner and one sponsor, we should start with a simple approach, using one application to implement our concepts. A team may also own multiple apps, if it doesn't negatively impact development quality and speed. It's critical to find the right balance, since too much code can cause cognitive load. However, two teams should not share ownership of the same app. If we introduce more teams and we start to impact independence and, or, a lack of clear ownership, we should move to a more distributed approach. In these cases... The apps should be split, so that each team is owner of one app, or no app is owned by multiple teams, which is demonstrated in scenario four.
• #25: We can now easily understand how to best assemble our architecture and split it into applications and libraries accordingly. The goal is to ensure the right balance between cohesion and loosely coupling. This will also help us reduce development effort and architecture complexity.
• #26: Our Final Architecture is quite simple, yet powerful. It has only four applications. The Home Insurance App, with all the user facing UI. The Customer portal App, that aggregates and manages the customer data. The Claims App, that has all the business logic related with claims. And then the Billing App, where payments and bills are processed. And it also has three libraries, the SAP and Guidewire connectors, that serve as integration wrappers to core systems, and the theme.