OutSystems - The Art of Designing OutSystems Architectures - NextStep 2012

www.outsystems.com © 2012 OutSystems – all rights reserved

The art of designing great Architectures in OutSystems

NextStep 2012

Francisco Menezes - OutSystems


Objective

Provide a comprehensive tool to help you become a great Architect in OutSystems

•  Not a prescriptive method

•  A systematic approach that will build your architectural skills in OutSystems


•  What is a Great Architecture

•  Start with a Reference Architecture

•  Examples and known patterns

•  3 steps to design a great architecture


Different perspectives, different goals

Business

IT & Operations

Information System

•  Easy to operate •  Easy to change •  Scalable

Great Apps

Great Delivery

•  Adapts to my needs •  Intuitive and clear to use •  Real time


Why is a good architecture important?

Supports planning

Reduces risks

Reduces costs

Facilitates change

Manages complexity

Drives consensus


4 Reasons for architectures to fail

1.  Poor and Inconsistent investment on design phases;

2.  Failure to understand the business context;

3.  Non disclosure of embedded features on involved technologies;

4.  Based on past unrelated experiences.


5 Goals for a Great Architecture

1. Aligns with Business effective support to Business Roles and Processes

2. Promotes Usability provides assets to improve User Experience (UX)

3. Maintainable adaptable to business and technical changing reality

4. Performant efficient use of current resources

5. Scalable by simply scaling the infrastructure


Positioning in Architecture levels and Agile Planning

Agile Planning Adapted from Cohn

Strategy

Portfolio

Product

Release

Sprint

Day

Level

Enterprise Architecture

Segment Architecture

Solution Architecture

Scope

Organization

Line of business

Function/ Process

Detail

Low

Medium

High

Impact

Strategic

Business

Operational

Adapted from FEA Practice Guidance of US

Target

All Stakeholders

Business Owners

Users and Developers


Why is it important to start with a Reference Architecture?

•  Speeds up the design of a new architecture;

•  Gets a common understanding of all Business users and Developers

•  Supports a systematic approach


Agile Platform – a great architecture foundation

•  Scalable Infrastructures;

•  User and Security Management;

•  Stack independent;

•  Multi-tenant;

•  Multi-lingual;

•  Easy integration;

•  A IDE to support architecting


A Reference Architecture in 4 layers

Layer 3 - Business interfaces, processes and logic that provides the features available to end users

Layer 4 – Global navigation and homepages to improve UX for each Business Role

Layer 2 - Core business logic and data that can be shared by different business applications

Layer 1 – Connectors to external systems or infrastructural extensions to your framework

Change

High

Medium

Low


Example

Consultants Sales Rep Marketeers

PDF Generator

Rich Widgets

Salesforce connector

Pardot connector

Charting Services

Account Contact Sizing Engine

Quote Quoting Engine

Quoting Tool

Proposal Builder

Customer Information

Sizing Tool

Intranet


No dependencies upwards

Consultants Sales Rep Marketeers

PDF Generator

Rich Widgets


Pardot connector

Charting Services

Account Contact Sizing Engine

Quote Quoting Engine

Quoting Tool

Proposal Builder


Sizing Tool

Intranet


Proposal Builder

Rich Widgets

Sizing Tool

Charting Services

Sizing Engine

PDF Generator


Pardot connector

Account Contact Quote Quoting Engine

Quoting Tool


Intranet

Bene"ts of a Service Oriented Architecture

Compos-ability

High

Medium

Low

Granular-ility

Low

Medium

High

Reusab-ility

Low

Medium

High

Loose Coupling

Low

Medium

High

Abstract-ion

Low

Medium

High

Auto-nomy


The single eSpace Fallacy

•  Rushing to service studio and start creating entities;

•  Building UI from dragging entities to screens;

•  Building all the logic in screen actions;

•  Violating SOA principles!

When designing a simple application, people tend to create a single eSpace ...

MyApp.oml

Processes Interface

Processes Interface Logic Roles

Timers Interface Logic Data

Logic Data Web block


The single eSpace Fallacy

... only makes sense if, strategically, you’re sure that any part of your application will ever be usefull in a Enterprise solution.

When designing a simple application, people tend to create a single eSpace ...

MyApp.oml

Processes Interface

Processes Interface Logic Roles

Timers Interface Logic Data

Logic Data Web block


Don’t loosen up…

… even with a very simple application don’t box yourself:

The single eSpace approach •  Is not cheaper; •  Doesn’t scale; •  Compromises SOA; •  Fuels future refactoring;

Get used to the multi-layer principle and let Service Studio help you.


But also don’t complicate…

… by making an intricate approach to a complex problem:

•  Use standards and sound principles to place everything into perspective;

•  Adapt known patterns to your speci#c problem.

Thomas A. Tinsley


Patterns Connector Extension UI

patterns

Logic

Data

Highly reusable components that may encapsulate services and protocols from external providers

• Actions to wrap the original services •  Exception Handling (throw exceptions instead of error

codes) •  (Single) sign in and session logic

•  Structures for inputs and outputs

•  Interface building blocks (e.g. a graph builder)

Web block

Layer 1 - Infrastructure Services

Goodies


External SQL Server

.Net/Java PDF lib

Simple Extension examples

PDFGenerator.xif

Logic

Data

• URL2PDF • ...

• Input/Output Structs • ...

PDF Generator

Legacy Entities

LegacyEntities.xif

Data

• PurchaseOrder • POLine • ...

•  Wrap an external library

•  Wrap Entities from an external Database


Connector example

Salesforce.oml

Logic

Data

• RenewSession • Account_Search • Account_Update • ... • Account_Struct • Opportunity_Struct • ...

Salesforce Connector

Logic

Data

• Login • Sforce_query • ... • Session_Struct • Return_Object • ...

Salesforce.xif

Extension to encapsulate external API • Map the underlying API

without type transformation • De#ne the input/output

Structures

Wraper eSpace for consumers • Session management with

external system • Match operations to Use

Cases needs and concepts • Transform basic types into

platform general structures/types

SalesforceConnector


Keep granularity when integrating with large APIs

Hundreds of APIs and Structures

... ... ... ... ... ... ...

Logic

Data

SAP Connector

SAP.oml

... ... ... ... ... ... ...

Logic

Data

SAP.xif

SAP Connector


Keep granularity when integrating with large APIs

Logic

Data

SAP Finance

SAPFin.oml

Logic

Data

SAPFin.xif

Logic

Data

SAP HR

SAPHR.oml

Logic

Data

SAPHR.xif

Logic

Data

SAP Materials

SAPMM.oml

Logic

Data

SAPMM.xif

... Split by functional groups

. . .

SAP Connector


UI Patterns examples

JQuery

Google Maps

Charting Services

Rich Widgets

Data

Logic

Data

Reusable JavaScript resource (only one cached version in a browser)

Web block to display Map Images for Map Markers

Actions to manipulate the Map

Structure to handle Map Markers

Data

Web block to display a chart

Structure for data series... Static entities for chart options...

Web blocks for reusable UI Patterns (Info ballon, Pop up, Autocomplete, Feedback Messages ...) Webblock

Interface Base Themes, Page layouts

Webblock

Webblock


Processes

Engine

Patterns Transparency services

External Core Entity

Core Entity

Interface

Logic

Timers

Data

Isolate Service components around Business concepts, shared by different composite applications

• Core Entities (CE) (master and associated details)

• Change operations on CEs •  Business Logs

•  Backoffice UI for crud edition and service con#guration

• Asynchronous data processing (classi#cation, data sync, statistics, ...)

Layer 2 – Core Business Services

Engine


Example - Core Entity

Employee.oml

Logic

Data

• Employee • OrganizationUnit • OrganizationUnitType • ... • EmployeeUpdate • EmployeeDismiss • OrganizationUnitNew • ... • BackOffice management

Interface

Why? •  Entity is reusable by several applications.

•  Make sure there is no other core entity that can be extracted from an existing application

•  Expose Core entities as Read only to ensure that transformation code is encapsulated, reinforcing abstraction and autonomy.

Employee

Directory Vacations Expenses ...


Example - External Core Entity

•  Master of the Entity is an external SaaS

•  Local cache makes it look like any other Core Entity service to consuming apps

Licensing Customer Info

...

Account.oml

Logic

Data

• Account (local cache) • Opportunity • ... • UpdatesFromSFA • ...

• Asynchronous fetch of updated info in salesforce

Timers Salesforce Connector

Account

Proposals


Example - Transparency Services

Buffer Tolls Info

Async. Transform.

Channel

Channel

Channel

Async. Feed

FTP Channel

FileUpload Vendor #1

FileUploadVendor #2

HTTP Req. Vendor #3

Fraud Control

... Toll Management

Toll transparency service

Financial Matching

Encapsulate and normalize information from multiple feeders. For the Consuming Apps is just another core entity

Different providers / different protocols Toll Transparency Services

Logic

Data

• Toll • TollUsage • TollBuffer

• ProcessBuffer • TollUsage_Update

• LoadFromFiles • LoadFromWS • ProcessBuffer

• BackOffice • Toll management • Error Handling

Interface

Processes

Timers


Sizing Engine

Example – Calculation Engine

Isolate calculation/transformation Engines.

Sizing Tool

Timers

Sizing Engine

Logic

Data

• Entities to con#gure rules • Inputs/output structures

• Calculation/transformation APIS

• Assynchronous calculations/transformations

• BackOffice for crude edition and con#guration Interface

• Sharable

• Strategically replaceable (without affecting consumers)

• Supports multiple versions


Interface

Logic

Data

Layer 3 – Composite Applications

End user Applications. Very dynamic, changing with business needs.

•  Role based UI to support use cases and UX Orchestration

• Can have it’s own entities, extending or correlating Core Entities

•  Business logic, to support use cases, that can not be isolated for common reuse

•  Process work$ow de#nition to orchestrate use cases

•  Permissions to de#ne Role based access to features

Processes

Roles


2. Core Business Services

1. Infrastructure Services

3. Composite Application

4. Ux Orchestration

Common look and feel between Applications

Customer Info

UX Widgets.oml

• Common Theme • Page Layouts • Header Webblock • Footer Webblock • Menu Webblock

Interface

Logic

Data • MenuItem

• AddMenu • DelMenu

UX Patterns

Proposals

Intranet


Avoid dependencies between composite applications…

•  … as it generates huge application footprints and increases deployment time Proposal

Builder Customer Info

Proposal Account

Customer Info

Proposal Builder •  Isolate Core business services, improving

granularity and reusability


Interface

Layer 4 – UX Orchestration

Mash up of composite application elements, optimizing UX for each Role.

•  Single login •  Role based navigation - Main menus • Home Pages with dashboards

• Cross application work$ows

•  Role management trough Users built in Application (EM on older versions)

Processes

Roles


Orchestration From External SaaS

•  salesforce Opportunity example Go to Quoting Tool,

with silent login, relating to current

opportunity

Display Proposal Information related to the opportunity

Can download documents

Sales Rep

Go to Proposal builder with silent login


3 Steps to architect a great solution

1. Disclose business needs and embedded features in used technologies.

Integration technology

User Stories and Roles

Points:13 Must Have

Information Architecture

UX expectations


1. Disclose

2. Match disclosed features against known patterns and layers.


UX Patterns

Composite Applications

Infrastructure Services

External Service

Connector

Core Business Services

Core Entiry

Application


1. Disclose

2. Match

3. Architect component inter- communication and services, to meet your speci#c needs.


Great Conception Happy Customer Relaxed IT


1. Disclose

2. Match

3. Architect



Q&A

[email protected]

OutSystems - The Art of Designing OutSystems Architectures - NextStep 2012

Technology

Transcript of OutSystems - The Art of Designing OutSystems Architectures - NextStep 2012