Architecture Certification PDF

 Architecture Certification Designing Apps using an architecture framework Why is architecture important ? usability -> from the point of view of the users funcionality +...

 Architecture Certification Designing Apps using an architecture framework Why is architecture important ? usability -> from the point of view of the users funcionality + As a set of functions that satisfy needs which relates the performance to the amount of resources used Efficiency + Maintainability + which relates to the effort needed to make modifications the ability Portability - which defines to more software between environments Reliability that software solution maintain - which ensures a can its performance over a period of time Security - to ensure that software solutions can protect information and data with other Compatability + to ensure that software solutions can work together systems Lack of Architectural concerns Poor service abstraction Business concepts not and abstracted correctly - to code - Business rules spread over different systems , and little no reuse Unmanageable > - systems not isolated from each other has other updating replacing system cascade systems ~ or a a effect on Inflexible and slow-movinglegacy systems > - Adapting legacy systems to business changes may be difficult inflexible systems take long time > - changes in complex and can a  architecture , the Without a good plan and well-defined application application ends called "Spaghetti. So Architecture architecture up with what's commonly a why is important ? - Drives consesus - Manages Complexity - Reduces Risk - supports planning Facilitates change - > - Reduce cost OutSystems Architecture Framework Outsystems Architecture Canvas the architecture framework to architecture canvas is a support application to design in OutSystems. It provides a systematic approach speed up architecture design. It is a multilayer framework composed of , 3 layers: End user, core and foundation should be used ? Why the architecture canvas -promotes the correct abstraction of Reusable services and components. Understanding and having a clear definition of the dependencies among all parts helpomize lifecycle independence Finally · , it helps minimize the impact of This leads to mountenance and effecient application changes -. easier more evolution. the architecture designing process this three-step process helps design the application. It's architecture fundamental to align the architecture with business-goals. Business must be oriented to architecture business needs and concepts should be translated into , so properly modules. this strategy allows the modules to evolve and scale with business , while ensuring independent life cycles between different lines of Business - the 3 steps arei > - Disclose + is where business concepts , integration needs and , non-functional disclosed this disclosure requirements are. Identifying Relevant user stories can achieve Understanding who will interact or access the application , what the roles are , and the kind of different actions each person can perform are also important questions to answer. - Organize- here concepts will be added to the layers of the architecture canvas. As the concepts start being organized , more concepts can be disclosed. In the end both tandem and of iteration disclose and organize work in require a but. During Disclose and the "talk" still about concepts and not modules ! organize , is > - Assemble + is where the concepts are assembled into modules. In this step , some to be. followed the concepts that relate to other should be principles need joined However concepts with , different lifecycles should be split into different modules if the related The third principle says to isolate reusable even concepts are. logic integration logic Reusable should be isolated the layer while from. Logic in wre , the integration logic ends up in the foundation layer This protects the , reusable core logic from external system changes by keeping them independent from each other. Finally , When possible , the architectural patterns should be applied. Once the completed the blueprint" process is , archicture is created. During the this process needs to be iterated Project ,. Finding the Right concept granularity the number of modules that need to be defined to implement the concepts depends on the concept of granularity to define an architecture , concepts don't need to be captured at very a low level. However the , correct granularity is influenced by the following criteria : > - complexity - a concept may be too vast to implement in a single module. Split into several modules to keep the complexity of each module it manageable > - Independent Lifecycles - even if the sub concepts are predicted to not result in a module smaller concepts required if the complex module , splitting a in is also functionality needs to be. This managed independently allows to parallelize development among different developers or keep different evolution paces for different business Sponsors there severat abstract > - service isolation + are integration patterns to correctly severat technical services , requiring to sport a concept in components according to the scenario Validating Module Architecture After designing the architecture and placing the modules in the correct layer of the canvas , is necessary to validate that the architecture created is good. In order to do this some basic rules need to be followed : Rule #1-no upward references this rule means that a module in a lower layer should not reference a module in a higher layer. An upward reference can create a cluster , where any I modules directly or indirectly have a circular dependency this · circular dependency can cause any module that references an element inside the cluster to be dependent on the entire Chester In this example since library E consumes end user [] , lat - A , any pair of elements inside the identified I E cluster are in circular. Another unexpected reference that end user B effect is is legitimely consuming Lend coreD. Not cluster , and it becomes dependent of the only its runtime will get unnecessarly large entire outdated but well constantly be  How to fix it ? the elements that find are bung consumed and move them to a lower layer. Inthis Case the reusable to itself If fets in the , more service in A a library eventually , to E. it same concept Rule #2 No side reference end-users among End user modules should not proude reusable servces · this ensures that they are correctly isolated allowing them , different lifecycles different versioning pases to have , due to different sponsors or project teams. This isolation is critical since end users are at the top of the hierarchy. A reference to such modulestends to bring along a huge set of indirect dependencies from layers. Eduar-end usere] In this example , enduser 1 is a consumer of # I I module thus reference on another end user , creating a side le this scenario will cause the end user 1 to also become dependent on a cluster that shouldn't affect If encuser needs to it- an e somethin a from another end-user module then we should , analyze what elements are being referenced and robablypromote to seemeto Comoulowever ,thi raa a se · a How to ? fix it the modules of B identify bung consumed by A and more those into a new Cor an existing if there is , a conceptual fit) towers layer module > - to fove module if it a is business related to > - a library if it is business agnostic  Rule #3 no cycles among cores or library 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 How to fix it ? Most of the times , if there is clearly an undesirable direction in the relation concepts must be moved to another module In addition to these rules , there are some extra recommendations : Recommendation #1 Core modules should not have front-end screens. Even if these screens are useful to support testing , they should be removed from the core module One of the of placed major dangers end-user and in an testing module. that keeping test screens on core modules is they can open up a security breach if they end up in production Recommendation #2 should be this setting that all public entities read-only , will ensure you to directly delete records in the are not allowing consumers create, update , or database. Instead , the consumers can use a core service that handles the business rules , such as validations or normalizations. It's necessary to make sure that all business transactions are implemented as public actions to fully abstract the core module and have a safe service exposed to other consumers Recommendation #3 Business shouldn't be in the foundation layer. this is a common umistake , but this layer need to be business agnostic so that it can be reused in any domain of application Recommendation #4 Core entities should not be in the foundation layer We must ensure that. the foundation layer has ,that only non-functional requirements. However does not mean that a foundation layer module cannot have entities at all If is necessary to create audit all to transactions. generic service a and create an aucht entity that is perfectly possible since it is , a case of supporting a non-functional requirement not business- , a -related Scenario Validating Apps Architecture Although validating the modules within each application is important , it is not enough to assure that the application's composition is correct. Four rules should be applied at the application level : Rule #1 Apply the rules and recommendations for modules. No upward references , no side references between end user modules and no circular · if these references rules are not correctly applied in each application there , is no point in trying to have a correct application composition Rule #2 Apply the same rules used for modules to the applications considering the, References between them. Note : the topmost module inside an application defines the canvas layer where it belongs  - # - End User App 2 M End User C T A Core A - - I Core ↓ ↓ I- - Foundation C In this example , if only the modules are considered , no architecture are present and this is a normal downward reference. However in terms of application composition a side reference is present across two , · this end user applications setuation is undesirable because the end user without. It important to remember app 2 including the end user appAB is that an end-user application should not provide servces to other apps How to fix it ? In this case , the correct thing to do is isolate the common modules that provide the services that multiple apps will consume · this common core app will support the functionality needed to both end-user apps Rule #3 Don't mix app ownership Having more than one owner for an application results in complex deployment management , since accountability for what has been changed becomes unclear If it , is not possible to concentrate the ownership of an application consider splitting it such way that ownership clearly in is , defined  Rule #4 Don't mix sponsors Application sponsors usually have different demands and work at different paces. For example , if a portal that allows executing simulations over different insurance lines of business , If all lines of business are under the same application any change , made to one of them cannot be released independently of the others. Therefore the slowest one well dictate the release cycle By. splitting into multiple apps , each line of business can determine the pale of its own deliverables Library Module Pattern Extension Pattern An extension that was generated by integration studio can be a wrapper to an the wrapper the the actions and the data externat code library - can contain logic , that code that of the external will expose the is inside library. this way things inside of the Outsystems environment can use all of the things that are coming from the external lbrary > - Example Wrap an externat library , wrap entities from an externat database Connector Pattern with two modules : extension module that be used to encapsulate pattern an can an external AP1 ; and a wrapper module to expose the normalized Apl to consumers InterestoneI In this connection example , the salesfora of provides the original · force is API to do a sates force query and the Wrapper (salesforce- Es) uses the original Ap to expose different actors that Ixif] - salesforce. do · this way the different queries details of the external. this abstracted its system are way easier and simpler to understand  An important consideration for the integration services of the connector pattern is to keep the right level of granularity of the Al For example. , when integrating with large instead of external systems like SAP where, there might hundreds of API , haung a huge integration service , it might make sense to spelt the large integration into number a API and functional this helps balance the of smaller integration per area , granularity botthneck that too and avoid a single might affect many consumers. And , not only , does help avoid potential bottlenecks but it could also make the solution easier to mountain. Consumers of the fenanual Apls would not be impacted by changes or additions to the HRAP Hundreds of APIs create smaller APIs per functional Structures and area to granularity and avoid balance the a single bottleneck that affect too many consumer ESAP-Is) Et ↓ SPLIT # - needs Integration patterns according to data the key point is that no matter what kind of integration is required, consumers of the coreservice always get the same type of abstraction and are unaware of the external system of records. When fetching data from an external system of records , there two of data are type : - summary fields used : for listing or typically searching entries these feelds don't time like customer change over , a name or change very rarely like the customer City - Detail fields only required : to display details for a single entry. these fields are more subject to frequent change and to be considered sensitive to be replicated , as a customer balance Decision Tree Decision to help select the integration pattern according, to data needs it's ok to Replicate (some) data and need to search ? or mashup that data in Outsystems dyes ↓ Cold Cache Summary summary felds & high volumes update order No change frequently ↓ No ? of changes ? ↓ No is Relevant ? ↓ No J Yes Batch Real time Queued Real- Ordered Real- sync Sync time time Sync sync X - - ↓ d ⑪ Direct are detailed fields often reused during a > - to obtain ? Integration period and are they costly hyes Lazy load details ↓ No More than one source yes for the concept ? S same - transparency ↓ No Service > -- End Direct Integration this pattern simply represents a creat integration with the external system using , the for integration service service abstractio In this customer data coming from ERP Scenario is an ,. Customer IS interfaces with the ERP abstracting a normalized tomer. - , as API both for Retrieving information , and performing transactions ↓ this creates the flexibility to change the externat system without #Customer - IS impact on core services , as long the Integration Service Ad ↓ is maintained. Also this sanario does not include entities Terr , & in Customer CS to keep local replica of data Not - a. keeping Replicated data outs , de ERP might be due to a business constraint , or because (almost) real-time demand is incompatible with hang a delayed data replication Pattern limitations > - extra load on the ERP each time data is retrieved -> More perceived latency caused by extra online communication with ERP - Impossibility to maximize the power of Outsystems aggregates and advanced queries to retrieve customer data of to combine it with other information customer-ts and the > a - constant need to extend a strong dependency on ERP team to provide new Apls each time a different data retrieval is avoid this dependency developers. required Typically to , tend to innapropriately Reuse the available Ap , for instance by using , a method that returns 50 fields , when only I are. required Advantages - data is always up to date Gold Cache Summary Data When there is the need to improve the performance of the integrations with externalsystems a good starting point is to cache , that doesn't change frequently This data , called "cold data". is Cold cache is used when it is too costly to synchronize the entire database and detail is only required for , single entries (not lists). While data must be present to search for only entry summary. the entre of them Synchronization is unnecessary when entry only 10% will be visited detect actually in When this pattern is implemented - data that frequently listed, only summary is joined searched or is eached (full detail for a single entry can be fetched directly on the external system) - full and frequent synchronization is avoided (summary information doesn't change often Cold Cache with Batch Sync cold the simplest to create the When implementing a cache , design approach is data model and to eaching set up a batch synchronization process manage the cached data Adding local entities to customer Cs well overcome the - limitation of the direct integration pattern and actually create full-blown a core service  Direct the integration and stable Instead With Integration service becomes simple. Replica & of providing a myriad of actions for different data Retrieval needs has to it only supply a method to Estomer , - Cs fetch all customer relevant data , updated since last sync # Customer CS has. ahmer to regularly synchronize information through the Integration service this synchronization should be unidirectional , to avid complex Ep merges of information from the ERP (the - master of data) to the fore service. On the opposite direction , when an update is made Customer-Cs must be careful to make sure on , you that the update is successful synchronously and committed in the ERP first (a write through policy ( Advantages Disadvantages Simpler Ap Data outdated may be > - - -enable data mashup in Outsystems less impact the system - on source - Core service customers not affected by the synchronization Isolate Synchronization Logic When the synchronization process is to complex and constantly turned , it is Recommended to extract it from the core service , further isolating Customer-CS from the externat system. Having a synchronization module as a pattern is because not only the consumers of the core service don't need to consume the synchronization logic but also allows for code independence which allows the updates of the two sets of code independently the external system is still the system of record and the two-way should be avoided because that can be synchronization , When possible , a complicated and this that updates lot more means are being done synchronously while the larger sync is being done asynchronously ECS conthisolated Another reason to do it is when the sync logic Etetomer L sy synchronization requires nC to orchestrate J Q several integrations for e. if g customers Itstomer-cs ,. & stored and customer are in one system ## contracts in another then the synchronization Customer , - Is needs to make sure that customers are ↓ synched before contracts since contracts TP Refer to customers Consumers of Customer - CS don't need to be impacted by the synchronization code. Additionally , if in the future the ERP is deprecated and replaced built in by functionality OutSystems stripping out the synchronization code , the Inthe example Customer-Syne , regularly fetching updated is one information through the integration service the syne into Customer CS - Customer - Cs still consumes Customer - IS to perform online transactions Advantages - Code independence Consumers of - Is not affect by sync orchestrate several CS's sync > - can Real time sync data that Normally, a cold cache with summary is required for search Listing or mashups , is requiring real-time sync very stable not However , some situations require summary information to include fields that need to be up to date in real time for the application to work consistently Here instead of synchronization to retrieve data at , using a process times to react to certain , it's possible immediately any change on the external In this to the system. case , is necessary to provde an API external system. has occurred so it can notify that a change  ECS with direct Integration Real-time the externat system of sync requires Elastomer API Vestomer - CS records to callback outsystems notifying some Lets M in real time The API and the IS modules change. isolate the completely cre cervice malist the agnostic to the externat system and to the synchronization process Advantages Disadvantages Simpler API Hore inter - - system dependency Tenable data mashup in Outsystems > - Not appropriate for a high load of changes > - less impact on the source system by not providing a queue -Data is always current Queued Real time Sync While the default real-time sync is relatively simple to implement , its not appropriate for a high whime of changes. When this is the case , the solution is to implement a queue , so the synchronization is processed in parallel BPTreacts to a.... Customer - CS inbound message ↓ # ~ time a inbound queue # * Quick insert of update Request in queue  Ordere Real time sync if the external system is prepared to fire multiple update requests concurrently there is no certainty that those Requests will be received and processed in the correct order Light BPT reacts to Ettomer- - CS L- inboundcluster related messages being received before , all related for all customer ↑ 2 wait processing , in correct messages order - Is enqueing an entry identifying that cluster # Erp Tr Send message with Sequence control Direct Integration through an ESB if there is an ESB which is providing publish and subscription services and its possible to the wore to the adapt the direct integration (Real time sync) to have service actually publish bus , and the externat system to be able to subscabe that information from the Bus u Customer Ettmer-Ap as T Subscabe ~ ↑ me ↓ ubun in publish is Lazy load Details the patterns above address the with summary common integration patterns when dealing data fields. What about the detail fields ? If its frequent to reuse details after them from the external it's recommended that fetching system , a lazy load pattern is used , to be done as fetching can be too costly on demand  ? How to implement > - when possible fetch data from local cache. If not found or outdated , obtain the entry from the external system and cashe it (read through eaching( the - cache details can hav an experation date to force refreshing it from source after a certain period > - Alternatively , before reusing cached data , ask the externat systems of record , for the last update time stamp of that information to compare with the local timestamp and decide if the entry is outdated be not -if summary data is also bung cached , have a separated detail entity to cache details > - to save space , have atmer doing regular cleaning outdated defeuls data Note : it's data common to combine different patterns : cashe summary regularly and lazy load details when needed Transparency Service this pattern typically provides information that may be coming from various external For example enterprise customers be ERP and medium-sized systems. , can in an customer customers in another ERP and small in a saas system Entomers # customersyna Q · T last there type with When are multiple sources for the same of information , usually different formats and Apls the process becomes , synchronization more complex Customer orchestrates the - Sync synchronization with all systems of records updating , a single customer data in Cestomer-CS Replica in. this creates the transparency service In this example , customer - CS is not able to update customers. this pattern is the most Common transparency pattern service , where information comes from different sources but doe not flow in opposite way Examples. are electricity or foll readings coming from different sources/formats. However if back extra module must be added , sending changes is a requirement , an driver) will the transaction Customer - IS abstract which interface (or actually send to the correct system #stomer - CS #dectomer- Sync - Estomer - Is * Tepi-Dr L Duv Santapur ↓ J ↓ E F - Eas In this decide driver to the case , the integration service will which use depending on type. of customer encountered Each driver expose the exat same All but they integrate the the with their specific external system , core service can then use integration service the simplified and synchronize or cache data as necessary , transparency serve can be When isn't to perform updates from the that the necessary core servce. In care integration could be service isn't even necessary because the deasion for where to retrieve the data handled by the the itself synchronization of core servce 1 Way Transparency service (simplification ( I testomers tomer-sync Q - - # I err ov Stir ↓ d J E AERP2 Bas Style guide architecture In terms of architecture , there are several elements -mainreusable theme that contains the main CSC styles and classes - the template module that contains the base definition (such as reference to the theme) and common layouts and menus that can be shared between several applications this module is automatically cloned when the first module is created - the patterns include and that standard reusable UI Widgets are , components So , why it is important to define a style Guide Architecture ? if it isn't done upfront , some issues can occur later. on In terms of performance - it is important to only load resources , such as images , ess , and