Best Practices for Designing and Building Integrations

Best Practices for Designing and Building
Integrations
24 June 2019
Tony Scalese, Vice President

AGENDA
> Alithya & Speaker Overview
> Data Discovery
> Tool Evaluation
> FDMEE / Cloud Data Management Key Components
> Q&A
> Recap & Wrap-Up

COMPANY HISTORY
3
2001
Hyperion
Planning
introduced
to the
market (1st
Essbase
embedded
app)
2007
Enhanced
Consolidation
practice with
world class
capabilities
2009
HPCM
introduced
to the
market –
Ranzal
design
review
2010
Established
Strategic
Finance
practice to
complement
our Planning
expertise
2012
Exalytics &
Performance
Testing Lab
Establish
multi
product
focus &
advisory
Proven business analytics leader with a
history of successful implementations
and continuous growth
1996
Ranzal &
Associates
Founded
2004
Acquired by
Edgewater
2016
Deepened
geographic
footprint
and EPM
Cloud
expertise
2015
Developed
Discovery &
Modern
Data
Architecture
Approach
2014
Introduced
Hosting,
Support &
Managed
Services
Offerings
2018
Ranzal &
Alithya join
forces to
form an EPM/
ERP Cloud
Powerhouse

ALITHYA OVERVIEW – EPM & ANALYTICS
4
Comprehensive Business Solutions
Our solutions drive improved business performance
through better decision making, strong customer
engagement, and optimized operations
Deep Partnership Drives Customer Value Adaptable Deployment Models
Diverse Client Portfolio & Industry Expertise
RetailEnergy/
Utilities
Team Highlights
Multiple Oracle
ACEs
Seasoned
delivery team
with avg 8 years
serving clients
Experienced
management team
with avg 15 years in
the company
Certified Cloud
Resources
Enterprise Performance
Management (EPM)
Analytics
Financial Services
Technology CPG and
Manufacturing
Healthcare
Outstanding
Achievement
in Big Data
100 Most Promising
Big Data Solutions
Providers
1,000+ Clients 2,000+ Projects20+ Years
Advisory
Services
Implementation
Services
Technical
Services
Hosting &
Support
Training
Services
Intellectual
Property

ABOUT THE SPEAKER
> Professionally:
> Working with EPM since 2000
> Vice President of Technology at Alithya
▪ With Alithya (formerly Ranzal/Vertical Pitch) since 2006
> Former Hyperion administrator
> Oracle ACE ACE Director
> Author, blogger, and Twitter-er (@fdmeeguru)
> Personally:
> Husband and proud dad
> Enjoy short distance running (5K)
> Avid foodie (and good wine)

WHAT
LEGACY THINKING
> WHAT: Build integrations that are easy to
understand and maintain, perform well
and grow with the business
> HOW: Leveraging the various
technologies that are available to us
> WHY: To ensure data accuracy and
integrity
7
HOW
WHY

WHAT
WHY FOCUS ON DATA INTEGRATION
> WHY: We recognize that data is the single
most important component of a financial
system. Commitment to building integrations
that ensure the accuracy and integrity of data
allows us to make business better decisions
> HOW: Evaluating the various tools that are
available to use and leveraging that which is
most appropriate in the pursuit of data
integrity
> WHAT: We build integrations that are
accurate, easy to understand and maintain,
perform well and grow with the business
8
HOW
WHY

TERMINOLOGY
> Source System: Any application that contains data needed for the
EPM solution.
> General Ledger, Sub Ledgers (Fixed Assets), Data Lake/Warehouse,
Saleforce.com, Workday HR, Flat file, Excel file, EPM applications
> Target Application: Any EPM application, cloud or on-premises
> ETL / ELT
> Extract: The process by which data is retrieved from a source system
▪ SQL queries, REST API, Proprietary extract mechanisms (ex: DATAEXPORT)
> Transform: Next slide
> Load: The process by which transformed data is inserted into the target
application
9

EPM INTEGRATION - DEFINED
> An integration is defined as the unique combination of:
> A source system from which data is Extracted
> A target system to which data will be Loaded
> The relationship that Transforms the source system data model to the
target application dimensional model
> Transformation is a combination of:
> Establishing the relationship between source system fields (columns) and
the target application dimensions
> Changing of the source system codes to the target application dimensional
members (mapping)
10

DATA DISCOVERY
> Data Discovery is the business user driven and iterative process of
discovering patterns and outliers in data – “Data Insight”
> Data Integration – sometimes called Data Preparation - is a key
component of Data Discovery
> Describes the process of:
> Identifying data sources
> Understanding data structure within the source system
> Determining relationships between source system and target system
11

GOALS OF DATA PREPARATION
> Data Quality
> Accuracy
> Performance
> Scalability / Sustainability
12

DATA SOURCES
> Source System Architecture
> On-premises vs. cloud based
> Relational vs. proprietary
> Extract mechanisms
▪ Flat file
▪ ODBC/JDBC
▪ REST API/Web services

DATA MODEL
> Data model is defined as:
> an abstract model that organizes elements of data and standardizes how
they relate to one another and to properties of the real-world entities.
14

DATA RELATIONSHIPS
> The relationship between the source system data model and the target
application dimensionality determines to which intersection data is loaded
> Data relationships can range from simple to complex and even conditional
based on data values
> Simple, no transformation: G/L natural accounts = target application account
> Simple, transformation required: G/L cost center (10065) defines Function
(Finance)
> Complex: Multiple source system fields determine target dimension value
▪ Ex: G/L Natural Account + Cost Center = Financial Statement Reporting Line
> Conditional: Natural account balance determines target application account
▪ Ex: Debit/Credit Balance determines if Account is loaded to A/R or A/P
> Data relationships can be a combination of one or more of the above types
15

DATA INTEGRATION RECAP
> Extract: Inventory the systems from which data will be sourced,
determine the mechanism to retrieve data from those systems and
secure a sample (or full) data set
> Transform: Understand the data model, determine the relationships
between the data model of the source system and the target
application dimensional model
> Load: Validate the E & T activities for:
> Accuracy
> Performance
> Sustainability
16

TOOL SELECTION CRITERIA
> Licensing
> Data Volumes & Performance Requirements
> Data Stewardship Ownership
> ETL Standards
> Integration Requirements (Targets)
17

ADDITIONAL DECISION CRITERIA
> Buy vs. Build
> Common Packaged Applications: FDMEE, Cloud Data Management, Data
Maps, Smart Push, OneCloud, ODI, ODI CS (aka DICS), ICE Cloud
> Custom Build: EPM Automate, REST API, Groovy
> On-Premises vs. Cloud
> On-Prem: FDMEE, ODI
> Cloud: Cloud Data Management, Data Maps, Smart Push, OneCloud, ICE
Cloud, ODI CS
▪ All integration tools have some on-premises footprint
> SaaS vs. PaaS
> SaaS: Cloud Data Management, OneCloud, ICE Cloud
> PaaS: ODI CS
18

OTHER INTEGRATION CLOUD SERVICES
> Oracle Integration Cloud (OIC, formerly ICS) is a PaaS solution that is
a more robust process orchestration and automation platform than
data integration
> Not intended to handle large volumes of data
> Transformations are rudimentary
> Oracle Data Integration Platform Cloud (DIP) is a PaaS solution that
incorporates machine learning and artificial intelligence powered
features including automated data migration and data warehouse
building, as well as machine assisted data profiling and governance.
> ODI and GoldenGate – large volumes and real or near real-time replication
19

EPM AUTOMATE VS REST API
EPM Automate REST API
Pros • Ease of use (command line based)
• Minimal impact due to updates from
Oracle
• Password encryption available
• High level of verbosity on execution status
• Supports concurrent processes natively
• Multi-platform
Cons • Error trapping is rudimentary
• Concurrent processes require multiple
deployments
• More complex (scripting/programming
needed)
• Potential upgrade impact
• Password in plain text (communication to
cloud is encrypted)
Optimal Use • File Transfers • Application maintenance (Dimension Builds,
Mapping Maintenance)
• Application execution (execute data loads,
run calculations)
20

CLOUD DATA MANAGEMENT / FDMEE COMPONENTS
> Target Applications
> Import Formats
> Maps
> Locations
> Data Load Rules
> Batches
22

TARGET APPLICATIONS
> Defines EPM applications for:
> Inbound data integration (Load)
> Outbound data integration (Extract)
> Register each cube individually using the Prefix option (.220+)
> Remove dimensions not applicable to the cube from the app definition
> Align common dimensions across all registered applications
> Ex: HFM Data Type (Custom4) and EPBCS Plan Element assigned to UD4
> Review application options
> Load Method
> Batch Size
> Drill Options (Enable, From Summary)
> Workflow Mode
23

IMPORT FORMATS
> Establishes the relationship between source system fields (columns) and the
target application dimensions
> Works in conjunction with the transformation logic
> Naming Convention: Source_Target
> 20-character limit: Don’t include _IF in the import format name
> Data Types: Numeric and Alphanumeric
> Formats: Delimited (Single or Multiple Data Columns) or Fixed Width
> Multi-column Expressions
> Column: Multiple periods of data such as forecast
> Driver: Multiple data columns for same period
> When adding a period indicator, be sure to complete source period mapping
> Source Column is an alias for the Workbench
24

MAPS
> The transformation logic to change a source system field value to a
target application dimensional member
> Maps work in concert with the import format
> The Target field (TargKey) in mapping supports 4000 characters but
the dimension fields on the data table sometimes supports less
> Account: 300, AccountX: 4000
> Other Dimensions Source & Target: 80
> High volume of explicit maps can degrade mapping performance
> Mapping is an art and a science
25

QUIZ – RAISE YOUR HAND PLEASE
> Question: What is the processing order for maps?
> Hint: This is a 3-part answer
> Answer: Maps process in the following order:
1. First in order of dimensions: Account, Entity, ICP, UD1
through UD20
▪ Extra Credit: The order in which the dimensions are
processed can be changed on the target application
registration
2. Then within each dimension in terms of type: Explicit,
Between, In, Multidimensional, Like
3. Finally, within each type, data load rule specific maps then
alphanumerically based on the Mapping rule name (non-
Explicit)
26

PARENT LOCATIONS
> Benefits:
> Maps can be shared across multiple locations
> Limitations:
> Data Load Rule Specific maps not available for child locations to which the
parent has been assigned
> Natively, All dimensions are shared
> Last one in, wins
> Map import/export must be performed at Parent Location
> Recommendations:
> Create Mapping parent location that will not process any data
27

LOCATIONS
> Data container
> Specific to each integration
> Security applied here
> Naming Convention
> Avoid business unit specific names that may
change over time
> End with Target application name (_OEP_FS)
> 20 Character Limit
> Other Considerations:
> Integration Options can be useful for scripting
> Functional Currency is used when integrating with
certain cloud services
28

DATA LOAD RULES
> A further subset of the data container
> Naming Convention: Location-Category-Data Type
> 80 Character Limit
> Import format setting is an optional override to the
import format assigned to the location
> Target Options can override the default integration
behavior
> Custom Options can be useful for scripting
> Source Options can be leveraged for automation or
streamlining end user usage
29

BATCHES
> Batches allow automation of the workflow process
> Batch Types:
> Data: Direct connection to a source system, flat file with Source Options completed
> Open Batch/Open Batch Multi Period: All integrations
> Batch: Collection of other batch types
> Conventions:
> Always start with Batch_
> Include Target Application Name (ex: OEP_FS) in batch name
> 50 character limit
> Recommendations:
> Avoid data batches
> Leverage Batch type to group different batches into a single execution
> Do not use the underscore (_) character for Open Batch
> Batch Groups can be used to filter but must be considered in concert with security design
30

OPA!
> A new light weight On-Premises Agent is coming for Cloud Data
Management that will allow data from on-prem systems to be loaded
to the cloud more seamlessly
> Supports Jython scripting as well as Java
> 4 events: Before/After Extract, Before/After Upload
> Additional technical capabilities:
> Clustering
> Parallel processing
> Synchronous mode with port 443
> Asynchronous mode, no additional ports
32

Q&A
> Agenda
> Company History
> Alithya Overview – EPM &
Analytics
> About the Speaker
> Start with Why
> Legacy Thinking
> Why focus on Data
Integration
> Terminology
> EPM Integration - Defined
> Data Discovery
> Goals of Data Preparation
> Data Sources
> Data Model
> Data Relationships
> Data Integration Recap
> Tool Selection Criteria
> Additional Decision Criteria
> Other Integration Cloud
Services
> EPM Automate vs REST API
> Choosing the Right Tool
> Cloud Data Management /
FDMEE Components
> Target Applications
> Import Formats
> Maps
34
> QUIZ – Raise Your Hand
Please
> Parent Locations
> Locations
> Data Load Rules
> Batches
> Safe Harbor
> OPA!
> Bridging the Data Bay
> Recap
> 16 Speaker Sessions
> Find Us
> Contact Information

RECAP
35
> Goals
> Data Accuracy
> Performance
> Sustainability
> Criteria
> Licensing
> Data Volumes & Performance
Expectation
> Process Owners
> Functional Requirements
> Application Build
> Think more broadly than a
single integration
> Utilize naming conventions
> Understand data security
requirements
> Remember how the
components work together
> Understand the data model of
the source system to build
“good” maps
> Always plan for automation

16 SPEAKER SESSIONS
36
Monday, 6/24:
• 11:00am – 11:30am (202): Become a RESTful Iron Man with ARC (the Application, Not the Reactor)
• 11:00am - 11:30am (204): Supplemental Data in the Cloud
• 2:15pm - 3:15pm (205): Best Practices for Designing and Building Integrations
• 3:45pm - 4:45pm (611): My Favorite Calc Code
Tuesday, 6/25:
• 8:50am - 9:50am (204): Keys to the Kingdom: Key Concepts to ARCS Application Design
• 10:00am - 11:00am (211): Client Success Story - Oracle FDMEE is the Cloud Data Hub at Legg Mason
• 11:45am - 12:45pm (611): I Can do WHAT with PCMCS? Features and Functions, Business Benefits, and Use Cases
• 2:15pm - 3:15pm (211): EPM Cloud Integration at CareFirst
• 2:15pm - 3:15pm (611): Empowering Users with Analytical MDX
Wednesday, 6/26:
• 10:15am - 11:15am (201): EPRCS: The reporting Swiss Army Knife
• 10:15am - 11:15am (602): Connected Planning Using EPM Cloud at Opus Group
• 11:45am - 12:45pm (211): Case Study: Using EDMCS to Solve Master Data Challenges
• 11:45am - 12:45pm (201): EPM Data Integration Panel
• 11:45am - 12:45pm (6A): Trend-Based Connected Planning at Vitamix
• 3:30pm - 4:30pm (204): A 2020 Vision for EPM Project Management
Thursday, 6/27:
• 9:30am – 11:00am (609): Deep Dive: Financial Close: The Best of Both Worlds - Welcome to the Hybrid Close
Visit us at Booth # 113

FIND US
37
infosolutions@alithya.com
You can email us questions:
Read our blog for insight and
find answers to your questions:
ranzal.blog
Visit our website to find the right
solution and learn how we can
help you:
alithya.com/oracle

CONTACT INFORMATION
38
Alithya
1025 Westchester Avenue, Suite 108
White Plains, NY 10604
Tel (914) 253-6600
infosolutions@alithya.com
20 West Kinzie Street
Suite 13046
Chicago, IL 60610
200 Harvard Mill Square
Suite 320
Wakefield, MA 01880
Tony Scalese
Vice President - Technology
Tony.scalese@Alithya.com

Best Practices for Designing and Building Integrations

More Related Content

What's hot (20)

Similar to Best Practices for Designing and Building Integrations (20)

More from Alithya (20)

Recently uploaded (20)

Best Practices for Designing and Building Integrations