Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a OutSystems User Groups - Introduction to OutSystems Architecture (Pune - 7 August 2021)
Semelhante a OutSystems User Groups - Introduction to OutSystems Architecture (Pune - 7 August 2021) (20)
Último
Último (20)
OutSystems User Groups - Introduction to OutSystems Architecture (Pune - 7 August 2021)
- 2. ✘ Poor Service Abstraction ✘ Unmanageable dependencies ✘ Inflexible, slow-moving legacy systems 2 Lack of Architecture concerns
- 3. ✘ Poor Service Abstraction ✘ Unmanageable dependencies ✘ Inflexible, slow-moving legacy systems 3 Architects hate spaghetti!
- 4. Drives consensus Reduces risks Facilitates change Supports planning Manages complexity Minimizes technical debt Why is Architecture important? 4
- 6. End-user Foundation Core Architecture Canvas 6 A Multi-layer framework to support Architecture Design ● Promotes correct abstraction of reusable services ● Optimize Life cycle independence among parts ● Minimizes impact of changes
- 7. End-user Foundation Core Non-functional requirements Services to connect to external systems or to extend your framework Reusable Services Business services Services around business concepts No Services UI and processes That provide functionality to the end users Architecture Canvas 7
- 8. Orchestration End-user Foundation Core Non-functional requirements Services to connect to external systems or to extend your framework Reusable Services Business services Services around business concepts No Services UI and processes That provide functionality to the end users Access Portals Cross-application processes and dashboards Architecture Canvas - before OS11 8
- 9. Orchestration End-user Foundation Core Non-functional requirements Services to connect to external systems or to extend your framework Reusable Services Business services Services around business concepts No Services UI and processes That provide functionality to the end users Access Portals Cross-application processes and dashboards Architecture Canvas 9 Applicable to versions prior to OutSystems 11
- 10. OutSystems Reusable services No services Core Services Applications External Producers Intranet/extranet users Corporate Databases APIs External Consumers NFRs Integration Services OutSystems in the Enterprise Landscape 10
- 12. End-user Modules Foundation Modules Core Modules B EU1 A X EU2 No Upward references Architecture Canvas Validation Rules EU2 becomes dependent on this entire cluster 12
- 13. End-user Modules Foundation Modules Core Modules B EU1 A X EU2 C Z No side references among end-user’s Architecture Canvas Validation Rules EU1 can’t be independent from EU2 and its dependencies 13
- 14. End-user Modules Foundation Modules Core Modules A B X Z Architecture Canvas Validation Rules 14
- 15. End-user Modules Foundation Modules Core Modules • No Front-end screens • Read-only entities (write using APIs) • No Business logic • No core entities No Upward references No side references among end-user’s Architecture Canvas Validation Rules 15
- 16. Application Set of modules defined in Service Studio that constitutes a minimal deployment unit for LifeTime Application layer Topmost layer of the modules inside the application End-user applications Core applications Foundation applications Concepts 16
- 17. No upward references No references among end-users Rule #1 - Layer your modules correctly 17
- 18. No upward references No references among end-users Rule #2 - Layer your applications correctly 18
- 19. End-user Application 2 End-user Application 1 End-user #1 Core A Core B Foundation B 1st project End-user #2 Core C Foundation C 2nd project 3rd project Rule #2 - Layer your applications 19 End-user applications should not provide services to other applications
- 20. Common Core Application End-user Application 2 End-user Application 1 End-user #2 Core C Foundation C Rule #2 - Layer your applications 20 End-user #1 Core A Core B Foundation B
- 21. Common application Module 3 Module 1 Module 2 Who is responsible? Owner 1 Owner 2 Application 2 Split Application 1 Module 3 Module 1 Module 2 Promote ownership Rule #3 - Don’t mix owners 21 Owner 1 Owner 2
- 22. Simulators Simulation Portal ... ... ... Auto Life Property Engines Policy Property business Auto business Life business Different sponsors have different paces Split Common services Life Suite Property Suite Auto Suite Simulators Simulation Portal ... ... ... Auto Life Property Engines Policy Property business Auto business Life business Each LOB can be deployed independently Rule #4 - Don’t mix sponsors 22
- 24. Business drives the Architecture design: ● Represent business needs and concepts ● Scalable with business growth ● Independent per LOB Business, Business, Business! 24
- 25. Step 1) Disclose business concepts, integration needs and NFR’s. User Stories and Roles Information Architecture Integration Technology UX Expectations 3 Steps for Architecture Design 25
- 26. End-User Foundation Core Business End-User User processes Foundation Integration needs & NFRs Core Business Business concepts Step 2) Organize concepts in the canvas Claim handling User Management ERP CRM Audit Customer Claim Contract Product Style Guide 3 steps for Architecture Design 26
- 27. Assembling principles: ● Join concepts if they are conceptually related ● Don’t join concepts if they have different life cycles ● Isolate the reusable logic from all the integration logic ● Apply known design patterns Customer_CS Customer_IS ERP Customer _Sync Synchronization with an external system 3 steps for Architecture Design 27 ● Step 3) Assemble by matching recommended architecture patterns.
- 28. ... to refine the architecture, as you disclose new concepts and more detail. Iteration Keep iterating these 3 steps 28 Disclose Organize Assemble
Notas do Editor
- What do we understand by Application or Software Architecture An application architecture describes the patterns and techniques used to design and build an application. This also gives you a roadmap and best practices to follow when building an application, so that you end up with a well-structured application which can be easily scaled as and when required. And if we ignore the Architecture side of our applications we’ll eventually reach what we call it as a spaghetti architectures after a period of time. This will results in several issues like - Poor service abstraction: where in your Services for core business concepts will not be correctly isolated and abstracted. Business rules will be spread over different systems and there will be no or very little reusable structure. - Unmanageable dependencies: So if System components are not correctly isolated from each other , updating or replacing a system will have a snowball effect on other systems. Example Loan - BL,HL,PL And eventually you will end up with a - Inflexible, slow-moving legacy systems: Adoptions of the business changes will be very difficult. If the system is complex and inflexible, changes can take a long time. Sometimes the technology is obsolete. And, the accumulation of core information and system dependencies over time can hinder any replacement.
- You may like Spaghetti as your snacks but i'm sure you will not like a spaghetti architecture for your application.
- So why is architecture design important? To [click] drives consensus among all players (multiple stakeholders with different expectation with the application) [click] to support planning (last feature) [click] to facilitate change (framework) [click] to manage complexity (Integrations , ESB) [click] which in overall will reduce risks [click] and technical debt The time that you will invest in Architecture planning and designing will help you to reduce time that you will spend on technical debt if you are ignoring the architecture design for your application.
- Let me introduce the Architecture Canvas, a framework to support Application Architecture Design that we follow in OutSystems
- The Architecture Canvas is a Multi-layer framework that provides a systematic approach to speed up architecture design and helps us in Promoting the correct abstraction of reusable services and components Maximizes Independent life cycles among all the parts of your architecture, by setting the correct dependencies among each other Minimizes the impact of changes, making it much easier to maintain and evolve your architecture
- Now in details we will see how these layers are segregated and which part of your application is handled by which layer. The bottom 2 layers isolate all the reusable services or components Foundation layer Business agnostic, reusable and non-functional modules Integration services to Connect to external systems - SAP, External database Extend your framework - Libraries, Reusable UI patterns - carousel, Themes NFR - auditing So anything which is not related to business and comes under these categories will be placed in the foundation layer. Core Layer , This layer will have Reusable services around business concepts. Business entities, business rules, Business transactions and business widgets. These services should be systems agnostic: Foundation modules abstract the integration details End-user Layer - which Support user interaction. All the User interfaces and processes, reusing Core and Library services to implement the user journey This ensure independence lifecycle of your application , One rule to remember that end-user applications should not depend on each other
- Before OS 11 the architecture framework used to have one additional layer which was orchestration layer. Cross application orchestration was necessary, because destinations (hyperlinks) across end users, a common practice in the web experience, were treated as strong dependencies, hence creating undesired dependencies across end user applications. This layer meant to isolate processes, dashboards and portal homepages, mashing up information from different applications to provide a unified user experience and keep applications independent
- If you are starting with OS11, you can simply disregard this layer
- Most probably, OutSystems is just another technology in your IT ecosystem, and while building your application using Outsystems you may need to integrate with other inhouse or cloud based systems Integration Services A Technical wrapper to external producers, normalizing data structures and abstracting integration complexity (error handling, authentication, etc.). No business logic should be placed at this level Non Functional Requirements Non-business functionality, reusable across any business domain, like an Audit Trail, UI Patterns, Style guides, Google maps ... Core Services Implementation of a reusable core functionality, with all the business rules, business transactions and business data Public APIs Composition of APIs that exposes the Services to external consumers - using REST, SOAP or other. No business logic is added at this level → technical wrapper to the real services implemented in the Core Services layer, translating those services to the agreed contract These 2 layers ensure my architecture survives: if we replace an external producer, there’s no impact on the core services (we only have to change the Foundation). As a final note, the 4LC is not limited to 4 layers as each layer may be broken down into sub-layers.
- Let me introduce the Architecture Canvas, a framework to support Application Architecture Design that we follow in OutSystems
- An upward reference tends to create a cluster where any 2 modules, directly or indirectly, have a circular dependency. In this example, the Foundation module (X) is - by definition - non-functional, and should not depend on functional or end-user modules. Another unexpected effect is that End-user 2 is legitimately consuming Core B, and becomes dependent of the entire cluster. Not only its runtime will get an unnecessarily large footprint, but it will also be constantly impacted (outdated) with changes made in modules that it should not even be aware of.
- End-user modules should not provide reusable services. This ensures that they are correctly isolated, allowing them to have different lifecycles - that is different versioning paces set by different sponsors or project teams.
- A cycle is always undesirable, since it brings unexpected impacts and hard-to-manage code. A cycle between modules indicates that the concepts are not correctly abstracted.
- As you can see, these 3 canvas rules are quite simple to understand and memorize. Just adding two extra recommendations
- Before going over the application composition rules, it’s important to understand what is the meaning of application in this context. In this context, an application is not a business application but a lifetime application.
- First, make sure your module architecture is following the rules, and only then go after the application.
- The same principles as before, but applied to applications, considering the application layer. Good news, same rules as before. Let’s look at an example.
- We can see that in this example we would have a side reference among end-user applications, which is not acceptable (as the same rules for modules apply to applications)
- Isolating the common referenced concepts into a new Core Application solves this problem.
- Having more than one owner for an application results in complex deployment management, as accountability for what has been changed becomes unclear. Promoting ownership is key. If it is not possible to concentrate the ownership of one application, consider splitting it in such a way that ownership is clearly defined.
- Similarly, avoid mixing sponsors. Let’s imagine we have a portal that allows executing simulations over different insurance LOB. If all LOB are under the same applications, the changes made to the Auto cannot be released independently. The slowest LOB dictates the release cycle. By creating independent applications per LOB, each one can determine the pace of its own deliveries.
- Now, let’s follow the process of designing an Architecture, following the canvas principles
- It’s fundamental that your architecture is aligned with business Goals! Business must orient the architecture. Only by translating business needs and concepts, the architecture will allow us to evolve and scale up with business, while ensuring independent life cycles between different Line of businesses
- Business alignment Identify relevant User Stories for each Role Information Architecture Identify the Information Architecture recognized by business users, to get the right names and hierarchy and match the navigation patterns with user expectations Integration impacts Disclose unknown features of the involved technology E.g., API is not stateless, and the communication protocol requires custom certification User experience Manage expectation Accessibility requirements Get as many concepts as possible - missing a concept might compromise the future of your applications
- A way to use the canvas to organize the disclosed concepts is to place each type of concept in the layer where it has an impact on. Examples of business elements: Core elements (Customers, Products) Composition of core elements (Contract) Represent an end user flow and complex business process (Claim handling)
- Remember to follow the assembling principles when matching your concepts into architecture patterns: Join concepts if they are conceptually related Don’t join concepts if they have different life cycles Isolate the reusable logic from all the integration logic Apply known design patterns
- These steps should be repeated as new concepts and details arise, making sure the architecture is always up-to-date.