An overview of the new Data Exchange for SaaS Usage Model is provided in this session. This usage model addresses the challenges that many organizations face when exchanging data with a SaaS provider. It also describes steps organizations can take in the planning and implementation phases to remediate these challenges.

1. SAAS DATA EXCHANGE
Vijay Ranjan Mungara
ODCA Data Services Team
Intel Corporation

2. AGENDA
 Purpose
 Audience
 Scope
 Challenges & Solutions
• Regulatory Requirements & Standards
• Data Management
• SaaS Provider Code Releases
• Data Security
 Summary of Industry Actions Required
2

3. OBJECTIVE
 Best Practices, challenges for SaaS Data Exchange that
organizations can use for planning and implementation
• Best Practices for data management applies
• Additional Challenges with SaaS is the focus of this presentation
 Challenges include integration, security & interoperability between
SaaS providers and Consumers
3

4. DEFINITION
4

5. REGULATORY REQUIREMENTS &
STANDARDS
 Compliance with local regulatory (Privacy, Storage, Mandates, Legal,
Country Laws, Audit Laws) requirements
 Outsourcing standard and/or policies
 Business continuity management standards and/or policies
 Risk management standards and/or policies
 Guidance, standards, and policies to manage and govern data and
security risks
5

6. CHALLENGES
6

7. CHALLENGES DATA OWNERSHIP /
LOCATION
 Data Ownership
• Irrespective of jurisdiction, data storage across multiple cloud service
providers could lead to data fragmentation and cause data ownership
problems when cloud services are terminated.
• Contractual Agreements between Provider/Consumer needs to consider
ownership of Intellectual Property & Integrity
 Data Location
• Data fragmentation or distribution across cloud service providers
• Applicable regulatory and legal framework of the jurisdiction
• Location of information storage and contractual controls
• Regulatory obligations compliance
7

8. SOLUTIONS
8

9. DATA GOVERNANCE
 Defines policies around
• Retention and disposition of corporate information
• Identifies people who govern these activities.
• Examples:
• APRA standards and guidelines, PCI DSS, ISACA’s CoBIT /COSO
frameworks, the Commonwealth’s Privacy Act, along with international
legislation such as Sarbanes-Oxley, HIPAA, AML, and sanctions screening
are increasingly driving regulators’ focus on the data management process
and associated controls.
9

10. DATA CONTROLS
Identify
•Data stores,
•business owners
• locations
•suppliers
•Relevant regulatory,
legislative
Classify and
perform a
valuation of data
assets
Determine
enterprise risk
drivers and risk
tolerance
Implement an
appropriate data
control framework
(examples include
CoBIT, COSO, and
ISO 27001/2)
Ensure regular
monitoring,
auditing, and
reporting activities
10

11. DATA MANAGEMENT
11

12. DATA MANAGEMENT
12
Lack of Data Documentation
• Infer data model from API documentation
Extending Data
•Weigh configuration vs. customization
Data Exchange
• Select best solution based on data usage requirement
Data Validation
• Use standard data management techniques

13. CHALLENGE: LACK OF DATA
DOCUMENTATION
Use traditional data management techniques to infer the data
model and structure from API documentation
• Steps
• Referencing the documentation to identify entities
13
• RESTful APIs typically have end points that represent entities
• Look for collections within the end points, since they can represent entities
• Build a conceptual entity model from the identified entities
• Build out relationships based on description
• Layer in the attributes from the documentation
• Review and refine
• Create the semantic mapping to the business’ canonical model
• Example overview
• Example documentation from a RESTful API to a customer record

14. CHALLENGE: LACK OF DATA
DOCUMENTATION - EXAMPLE
14
Customer API JSON response
Attribute Description
cutomerGuid Unique identifier (GUID) assigned when created
alternateId Alternate key identified from another system
firstName The customer’s first name
middleName The customer's middle name or middle initial
lastName The customer's last name
email The email address for the account
dateOfBirth The birthdate of the user of the account, ISO 8601 (YYYY-MM-DD)
gender The gender of the customer. Format is ISO 5218
addresses A collection for address information
addressGuid The unique identifier for the address
type The location/purpose for an address.
line1..3 The first, second, and third lines of the customer's address
city The city associated with the address
stateProvince The state or province, ISO 3166-2. Maximum is three characters.
postalCode The ZIP code or postal code.
country The region/country, ISO 3166. Maximum is two characters.
preferred Default ""false"". At most one address may be preferred
phones A collection for phone information.
phoneGuid The unique identifier for the phone number
type The purpose or type of phone number.
number The actual phone number
internationalPrefix The international calling code for the phone number.

15. CHALLENGE: LACK OF DATA
DOCUMENTATION - EXAMPLE
15
Semantic mapping
Canonical Internal System 1 SaaS Service 1
Customer Interface
Entity Attribute Entity Attribute Attribute
Customer Customer Identifier customer customer_id alternateId
External Customer
External Customer
Mapping
Identifier
customer_account_map ext_customer_id customerGuid
Customer First Name customer first_name firstName
Customer Middle Name customer middle_name middleName
Customer … … … …
Customer Address Address Type customer_address address_type addresses.type
Customer Address Address Line 1 customer_address address_line_1 addresses.line1
Customer Address … … … …
Customer Phone Phone Type customer_phone phone_type phones.type
Customer Phone Phone Number customer_phone phone_number phones.number
Customer Phone … … … …
… … … … …

16. CHALLENGE: EXTENDING DATA
16
Configuration is a better option than customization
Configuration Customization
Supported out of the box Requires custom coding
Vendor should support functionality between
versions
Requires testing with each vendor upgrade
Limited to what the vendor offers in terms of
configuration
Build anything that is required

17. RELEASE UPGRADE PLANS
17

18. SAAS PROVIDER CODE RELEASES
Challenges
• Frequent Provider Releases can cause
• Inconsistencies
• Mismatch in the version of Data
• Breakage in data exchange process
• Errors in Code, Runtime, Interface & data
• Service consumers can’t always upgrade at the same time
• Changes in data content, context and format
• Appropriate release times needs to be co-ordinated so as to
minimally impact organizations’ IT systems.
18

19. SOLUTIONS
19

20. RELEASE PLAN (PROVIDER) AND
UPGRADE PLAN (CONSUMER)
 Providers should make a detailed release plan for service
consumers, this plan should identify
• Important milestones
• New technical specification
• When (and how) the service consumers can execute beta testing if
necessary, when the new version of code will be officially available, and
when the old version of code will no longer be available
 Based on the provider’s release plan, service consumers should
• Create their own upgrade plan to decide when they
• Should identify the impact scope,
• Need to complete the code revision and testing,
• To upgrade their IT systems that are influenced by this provider code
release. 20

21. RELEASE PLAN ESSENTIALS
Non-production Test Environment.
Phased Upgrade Deployment Strategy.
Announcement and Reminding Mechanism.
Upgrade Timing Choice.
Partial-to-All Approach.
21

22. DATA SECURITY
22

23. DATA SECURITY
 Controls that can provide the appropriate level of data protection.
 Existing threats of tampering or theft of data in transit implies that
most sensitive information is already encrypted in transit.
• However, recent data theft has occurred while data is at rest—
underscoring the need for cloud-based data security.
 The ODCA Data Security Framework and the Security usage model
discuss in detail data security and define requirements associated
with increasing data security in the cloud. In particular, the Data
Security Framework documents the following data security controls:
 References
• http://www.opendatacenteralliance.org/docs/Data_Security_Framework_Rev1.0.pdf
• http://www.opendatacenteralliance.org/docs/Data_Security_Rev1.0.pdf
23

24. SUMMARY OF INDUSTRY ACTIONS
 The following actions are required by the combined solution
provider and consumer communities:
• Solution providers need to build better data management tooling into
cloud services.
• Solution providers should provide clear documentation about what data is
managed by their SaaS solution. This documentation ideally includes the
following:
• Conceptual data model of the solution
• Data dictionary of the data managed by their solution
• Mapping of the conceptual model to the APIs and interface elements
 The industry needs to continue to develop and adopt standards for
accessing data, specifically in the areas of querying and reading
data.
24

25. THANK YOU

26. 26

27. © 2 0 1 4 O p e n D a t a C e n t e r A l l i a n c e , I n c . A L L R I G H T S R E S E R V E D .