Decision Service Development Lifecycles typically follow these patterns: 1. Traditional waterfall model with business authoring stopping at UAT, and business simulation used until pre-production. Development of isolated decision services. 2. Agile model provides an operational decision management platform as a service, allowing for more dynamic changes to decision logic without full redeploys. This enables business authoring, simulation, and execution in pre-production and production with more agility but also more risk. 3. Topologies recommend functional isolation of workloads like business authoring, simulation, and execution across development phases and environments with increasing restrictions on access and change as you move from development to production.

1. © 2015 IBM Corporation
2475 - Best practices in
IBM Operational Decision
Manager Topologies
Pierre FEILLET – ODM Product Architect
feillet@fr.ibm.com

2. Agenda
• What’s new in ODM 8.7.0
• ODM Standard Architecture & runtime elements
• Recommended topologies
• Decision Service Development Lifecycle
• Business Rules everywhere
• Best practices
2

3. What’s new in ODM
8.7.0

4. ODM 8.7.0 Editions
• Standard
• Decision Center
• Decision Server Rules
– Coming from ILOG JRules
– Mostly stateless decision
– Decision Runner
– Decision Service projects
– HTDS extended to RES/JSON exec
• Advanced = Standard +
• Decision Server Event
– Continuation of WebSphere Business Event
– Stateful execution
– Event driven
– WAS ND cluster with XS
• Decision Server Insights
– Dynamic modeling to define Events, Entities & detection rules to search
for situations
– Server Grid with events & data in memory
– WAS Liberty + WXS
4

5. ODM Standard
Architecture

6. ODM Standard - Concept of Operations
6
Decision Server
Development
Operation
Continuous
Improvement
Rule Execution
Server
JEE/J2SE
Rule Execution
Server
JEE/J2SE
Rule Designer
(Eclipse)
Rule Designer
(Eclipse)
Decision Center -
Decision Validation
Services
Decision Center -
Decision Validation
Services
z Rule Execution
Server
z Rule Execution
Server
COBOLCOBOL
Decision Center
Repository
Decision Center
Repository
IT Architect
IT Developer
Business Analyst
Process Owner
Business UserBusiness Leader
Code
Generation
Deploy
Synchronize

7. ODM Standard Component Organization
7
•Designer
• Decision Center
• Business Console
• Enterprise Console
•Decision Server Rules
• Rule Execution Server
• Rule Execution Server web
console
• Hosted Transparent
Decision Service
• Scenario Service Provider
• Decision Warehouse
• Rule Sessions
• eXecution Unit

8. ODM Standard Component List
8
Component Acronym Description DB tables SIBus
Decision Center DC Web consoles + the DM authoring repository to store rule
and event projects
Decision Center tables None
Decision Server / Rule
Server Console
RES Console Executable Decision Service mgt through RuleApp/ruleset
assets
Rule Execution Server
tables
None
Decision Server / Rule
eXecution Unit
RES XU Rule server core runtime deployed as JCA or Pojo Rule Execution Server
tables
None
Decision Server / Rule
Sessions
Rule
Sessions
Rule runtime components available as EJBs or Pojo None ODM Bus
Decision Server / Decision
Services
Custom or OOTB JEE artifacts that encompass the
invocation and the decision logic (RuleApp/Ruleset). Are
based on Rule Sessions.
None None
expected
unless
MDB used
Decision Server /
Scenario Service Provider
SSP Test and simulation rule runtime
DecisionRunner war added in 8.7.0 for new
Simulation
None None
Decision Server / HTDS HTDS Dynamic Web Services None None
Decision Server /
Decision Warehouse
DW Runtime that listens and store decisions Decision Warehouse
tables
None

9. A full fledge Enterprise Proposal
9
System z Enterprise 196 (or 114) +
LPAR, Sysplex
 100% Java product on
distributed plus a native
secret sauce in zRES
 OS
 Distributed including
z/Linux
 z/OS
Power or Intel blades
z/VM z/OS
z/Linux
WAS ND
& L
WAS ND
CICS
ODM ODM
distributed
WAS ND Other AS
 Works with a variety of stacks
 WAS ND, WAS Liberty profile (8.5.5.3) on distributed & z/OS
 zRES Lightweight server for z/OS, run standalone and in
CICS
 JSE Rule Execution Server & rule engine
ODM
ODM Technical Detailed System Requirements
Distributed
WAS
Liberty
WAS
Liberty

10. ODM Standard Consoles & Touch Points
10
Decision
Center
Decision
Server
ODM cell
Rule Designer
Decision Center
Consoles
Desktop
WAS Administration
Console
Rule Execution Server
Console
DC Ant Tasks
DS Ant Tasks
Synchro over
HTTP(S)
Executable
artifact
deployment
over HTTP(S)
All Consoles, synchronization, deployment going through HTTP(S)
HTTP(S)
HTTP(S)
HTTP(S)
HTDS WS endpoints
HTTP(S)

11. Zoom on Decision Server / Rule Architecture
11
RuleApp &
Ruleset archive deployment
Rule Sessions EJBPOJO
Engine JCA
Custom
Decision
Services
eXecution
Unit
Management
Console
RuleApp/Ruleset
Repository
Engine
Engine
Mgt
Notification
JMX/IP
Management
Model
Decision
Warehouse DB Decision
Traces
SSP
Testing & Simulation backend
Includes
DecisionRunner
JMX
11
Hosted
Transparent
Decision
Services
WSWS
WS, JSE, Message,
your choice
WS, JSE, Message,
your choice

12. RES Console
• Workload
• Only management of the rule executable artifacts (RuleApp,
ruleset, eXecutable Object Models)
• Execution restricted to diagnostic and interactive testing
• Notification to eXecution Units when a new artifact comes
available
• Design
• In memory stateful webapp on the top of the RES DB
• Contains a JMX Model
• Kind of WAS Deployment Manager for Decision Services
12

13. RES What If Scenarios
• What if RES Console shuts down
• What do we loose
– Deployment of new ruleapps/rulesets versions through HTTP(S)
– REST Mgt API become unavailable
– Execution statistics are on hold
• What do we keep
– Rule execution remains fully operational
– Direct deployment to the RES DB remains possible
• Restart to dynamically get back these functionalities
• What if RES DB goes down
• XUs will not be able to read rulesets asked but not in memory
• Execution remains fully operational for all rulesets already in
memory
13

14. RES Console In or Out a Cluster
• Deployed in a cluster
• Shared RES DB
• Pros
– Included in a Decision Server cluster – no adhoc server
– No SPOF
• Limitations
– RuleSession Interceptor not supported
– 1 only RES Console diagnostic supported at a time
• Diags run in parallel not supported
– Round robbin load balancing dispatches deployed artifact deployed
over http(s) across the different RES Consoles
• All deployed artifacts are stored into the shared DB
• Must refresh each RES Console with the DB to see the artifacts
deployed through the other RES Consoles
– Imply a local deployment flag for the SSP
14

15. RES Console In or Out a Cluster
• Deployed apart a cluster
• Install the RES Console on a separated server
• Pros
– All features supported
– All deployments go to the singleton web app and underlying DB
• Cons
– Needs a dedicated server
– SPOF but with limited impact if it fails
15

16. RES Notification Protocol
• IP
• RES Console hostname/IP & port number specified in each
eXecution Unit to get notified
• JMX
• Works in a WAS Cell or equivalent giving a JMX MBean server
federation
• RES Console defines its RES model top level MBean
• Each XU defines its MBean
16

17. ODM Standard
Topologies

18. How to choose your ODM topology
18
What is my Decision Management scope?
Decision servicesSituation detection
Dev phase
Dev Integration Testing Production
HA/DR
What is the workload nature ?
Event processing Remote/Local decision
execution
Business decision Validation through
Simulation and Testing
What is the platform?
distributed z: z/OS, z/Linux Hybrid Cloud
User Testing PreProd

19. ODM Standard Topology cheat sheet
• Abbreviations for product scopes
• ODM: Full platform
• ODMR: Rules only
• ODME: Event only
• ODM/DC: Decision Center
• ODM/DS: Decision Server
• ODM/DSR:DS for Rules only
• WAS ND topology concepts
• ODM Profile templates delivered for
clustered DC & DS
19
Cluster
DMGRNode Agent
Server
Server
Node Agent
Server
Server
Dmgr’s nodeCustom nodeCustom node
Cell

20. ODM Copper
DC + DS combined in a standalone server
ODM Bronze
1 cell with 1 DC server + 1 DS Server
ODM Silver
1 cell with a single cluster for DC & DS
ODM Gold topology
1 cell with a DC cluster & DS cluster
Separation between business authoring from execution
Cover all product usage including business authoring, execution and simulation for
rule and event
Best tradeoff between Performance, HA, and cost
Platinum topologies
 All upper topologies that provide more workload separation and usage
specialization
Client App cluster can be added in this cell or run in a separated cell
Simulation is isolated from business authoring & pure execution
ODM Topologies at a glance

21. Cell
ODM Standard Gold topology: DC + DS clusters +
RES Console
Node Agent
Cluster Member 2
XU, SSP, HTDS, in
option Custom Decision
Services developed on
RES Rule Sessions
Cluster Member 1
Decision Center
Deployment Manager
Node Agent
Cluster Member 3
Decision Center
Decision
Center
Cluster
Decision
Server
Cluster
Cluster Member 4
XU, SSP, HTDS, in
option Custom Decision
Services developed on
RES Rule Sessions
Decision
Center DB
Decision
Server Rule
DB
Decision
Warehouse
DB
IP Sprayer
IHS
Server 1
RES Console
• Functional
separation/isolation of
workload
• Several cells for
staged dev lifecycle
• RES XU deployed at
Node level
• Datasources deployed
at cluster level
• SSPs are directly
referenced on each
member from DC
• Remote ClientApp
cluster run in another
cell or can be added to
the ODM cell
• Failover
• Similar types of
workloads grouped
together
• Can scale individual
clusters as needed

22. Cell
ODM: DC + DS + RES Console + Remote Client
App clusters
Node Agent
Cluster Member 3
XU, SSP, HTDS, in
option Custom Decision
Services developed on
local RES Rule
Sessions
Cluster Member 1
Decision Center
Deployment Manager
Node Agent
Cluster Member 4
Decision Center
Decision
Center
Cluster
Decision
Server
Cluster
Cluster Member 6
XU, SSP, HTDS, in
option Custom Decision
Services developed on
local RES Rule
Sessions
Decision
Center DB
Decision
Server Rule
DB
Decision
Warehouse
DB
IP
Spr
aye
r
IHS
Server 1
RES Console
• Functional
separation/isolation of
workload
• Several cells for
staged dev lifecycle
• RES XU deployed at
Node level
• Datasources deployed
at cluster level
• SSPs are directly
referenced on each
member from DC
Cluster Member 2
Client Apps invoking
remote Decision
Services
Cluster Member 5
Client Apps invoking
remote Decision
Services
Remote
Client
App
Cluster

23. Cell
ODM Standard – Decision Center cluster
Cluster Member 1
Decision Center
Deployment Manager
Cluster Member 2
Decision CenterDecision
Cluster
Decision
Center DB
Node Agent Node Agent

24. Cell
ODM Standard - Gold Decision Server
Node Agent
Cluster Member 1
XU, SSP, HTDS, in
option Custom Decision
Services developed on
RES Rule Sessions
Deployment Manager
Node Agent
Decision
Server
Cluster
Cluster Member 2
XU, SSP, HTDS, in
option Custom Decision
Services developed on
RES Rule Sessions
Decision
Server Rule
DB
Decision
Warehouse
DB
IP
Spr
aye
r
IHS
Server 1
RES Console
• Functional
separation/isolation of
workload
• Several cells for
staged dev lifecycle
• RES XU deployed at
Node level
• Datasources deployed
at cluster level
• SSPs are directly
referenced from DC
• Remote ClientApp
cluster run in another
cell or can be added to
the DS cell

25. Cell
ODM Standard - Single cluster
Cluster Member 1
Decision Center,
XU, HTDS, SSP,
Potentially customer
Decision Services based
on Rule Session API
Deployment Manager
Cluster Member 2
Decision Center,
XU, HTDS, SSP,
Potentially customer
Decision Services based
on Rule Session API
Application
&
Decision
Cluster
Decision
Center DB
Decision
Server Rule
DB
Decision
Warehouse
DB
• RES XU deployed at
Node level
• Datasources deployed
at cluster level
• SSPs are directly
referenced on each
member from DC
Server 1
RES Console
Node Agent Node Agent

26. Cell
ODM/DSR - Testing & Simulation cluster
Deployment Manager
Decision
Server Rule
DB
IP
Spr
aye
r
IHS
Cluster Member 1
XU, SSP
Cluster Member 2
XU, SSP
Test &
Simulation
Cluster
Server1
RES Console
Node Agent Node Agent
• RES XU
deployed at
Node level
• Datasources
deployed at
cluster level

27. ODM Standard - Standalone server
Server
Decision Center, XU,
SSP, HTDS, potentially
custom Decision Service
Apps developed based on
RuleSession API
Decision
Center DB
Decision
Server Rule
DB
Decision
Warehouse
Full ODM Standard running in a single server
Includes all runtime parts for web decision authoring, test and execution

28. ODM - 2 servers
Server
Decision Center
Decision
Center DB
Server
RES XU, HTDS,
potentially customer
Decision Service based
on the RuleSession API
Decision
Server Rule
DB
Decision
Warehouse
Decision Center Decision Server
Decision Center on single server + Decision Server single server
2 servers environments:
• no failover
• 2 minimal # of JVMs
• easy to create (create standalone profile)
• Automatic DB creation

29. Operational Decision Management
Scope
Functional
restriction
Project
Phase
Recommended
Topology
ODM Standard
meaning DC + DS for Rules
Dev ODM - standalone
Test ODM – from 2 servers to DC + DS cluster (Gold)
Prod ODM DC + DS clusters (Gold)
ODM / Decision Center Dev ODM/DC standalone
Test ODM/DC 1 cluster
Prod ODM/DC 1 cluster
ODM / Decision Server Dev ODM/DS – standalone
Test ODM/DS - 1 cluster
Prod ODM/DS – 1 to 4 clusters
ODM/Decision Server for Rule Rule Dev ODM/DSR – standalone
Test ODM/DSR – 1 cluster
Prod ODM/DSR – 1 or more clusters
Rule Simulation Dev ODM/DSR/TS – standalone
Rule Simulation Prod ODM/DSR /TS– 1 cluster
ODM Standard Topology Catalog

30. Decision Service
Development Life
Cycle

31. Decision Management Development Life Cycle
In a strict isolation required between types/purposes of environments:
• DEV: application developers have access to “DEV” only , purpose is application dev and
basic function testing
• SIT: integration testers have access to “SIT” only, purpose is integration and function
testing
• User Acceptance Test: user acceptance testers have access to “UAT” only, purpose is user
testing
• PREPROD: function and integration proven in earlier environments, purpose of this env is
largely perf testing
• PROD - apps were proven in earlier environments. Barely anyone has access to this env, it
is tightly regulated.
DEV SIT UAT PREPROD PROD

32. DEV SIT UAT PreProd PROD
Decision Management Life Cycle
 Features are deployed in phased environment depending on purpose
 Business authoring
Business Object Model and Rule Editing
 Business Simulation & Test
Create and run Business Test Suites and Simulation to guide and improve
decision logic
Champion/Challenger comparison on KPI computation
 Execution
Decision run
Business Authoring
Execution
Business Simulation & Testing

33. DEV SIT UAT PreProd PROD
Classic Decision Management Life Cycle
 Development of delimited Decision Services
 Business Authoring stopping most likely at UAT
 Business Simulation used until PreProd max
Business Authoring
Execution
Business Simulation & Testing

34. Agile Decision Management Life Cycle
 Agile ODM
 Provide an ODM as a PaaS with change/extension of the decision logic without
starting back from Dev environment
 LOB leverage business authoring, simulation and apply their corporate decision
logic on their data
 Business Authoring and Simulation available in PreProd and even Prod
 More agility coming with more risk in production
 Need governance and workload isolation to handle business authoring,
simulation and execution and avoid regressions
DEV SIT UAT PreProd PROD
Execution
Business Simulation
Business Authoring

35. ODM Deployment across phases
 Each life cycle phase is mapped into an environment
 Each environment is a WAS cell (or equivalent in other AS)
 Decision Server deployed in isolation by phase
 Decision Center can be shared or isolated per phase
1 or more cells dedicated by phase
Phase environment contain 1 DC (cluster) when business
authoring required or
1 unique shared Cell with Decision Center + multiple Cells for
Decision Server
This configuration is the most commonly used
Multiple DC are possible for sandbox

36. Shared DC across environments
• One Decision Center managing multiple Decision Servers
• DC clustered with a HA/DR DB
• User access, Branches mgt for multi team/releases activities
• DC and DS can be split into 2 isolated envs
• Online and offline RuleApp/Ruleset deployment supported in DS
Decision
Center
Decision
Server
DC env
Decision
Server
DS env
DM for Dev DS for
Integration
Testing
Executable Decision artifact deployment over HTTP
Decision
Server
DS env
Decision
Server
DS env
DS for
Business
Simulation
and
Testing
DS for
PreProd
Decision
Server
DS env
DS for
Productio
n
DS env

37. SDLC – Shared Decision Center
 Pros
 One source of truth for business rule authoring
 Deploy on all Decision Servers; Multiple DS/RES are supported by
DC
 HA with DC and DS in cluster
 Leverage project branch and merge in DC and deploy executable
rules on the various DS
 Access to projects and DS scoped by groups & users in DC
 Isolation is preserved for the execution runtime
 Cons
 Doesn't allow DC customization for one phase only (Dev, Test or
Prod)
 Comments
 Applied by most customers
 Leverage clustering and HA/DR DB
Best practice is to minimize the number of DCs and have 1 source of
truth

38. Decision
Center
Decision
Server
ODM env
ODM for Dev
Decision
Center
Decision
Server
ODM env
ODM for
Integration
Testing
Decision
Center
Decision
Server
ODM env
ODM for
PreProd
Decision
Center
Decision
Server
ODM env
ODM for
Production
ODM Standard Fully isolated environments
Project Export/Import
Executable artifact deployment
Decision
Center
Decision
Server
ODM env
ODM for
Business
Simulation
& Testing
One Decision Center per environment
DC Synchronization through Rule Designer
Export/Import of Rule Projects between DCs
Export/Import of RuleApps between DS/RESs
DC and DS/Simulation in PROD depending on the Agility level

39. SDLC – Full Isolated Environments
Pros
Isolation. We have a full ODM Standard runtime in a single cell
HA with DC and DS when clustered
Isolation of authoring and execution by phase and cell
Cons
Multiplication of JVMs
1 DB per DC to administrate
DC Repository content has to be synchronized across cells from Dev cell to Prod
cell
DS Repository is exported/imported, or rebuilt from Decision Center or Rule
Designer
Each Decision Center will have its local version of Rule & Decision projects
Comments
This pattern is applied by clients who privilege a full ODM Rule environment
including possibly Rule Designer at each phase of the governance cycle.

40. Business Rules
everywhere

41. zRule Execution Server
Stand-alone
WebSphere Application Server
for z/OS
WOLA
CICS
COBOL
Application
Rule Execution Server
for WAS for z/OS
COBOL <-> Java
Marshaller
COBOL
Generation
Rules
Generated
COBOL
JVM ServerJVM Server
zRES
zRule
Execution
Server
IMS
COBOL
Application
z/OS Batch
COBOL
Application
COBOL
Generation
Rules
Generated
COBOL
COBOL
Generation
Rules
Generated
COBOL
DS StubDS Stub DS Stub
Decision invocations flavors in z/OS
11 22
33
11
33
22
zRES
RES on WAS on z/OS
COBOL gen
3 options

42. ODM in the Clouds
• ODM Patterns
• in PureAS (client IT)
• In Pure Service (SoftLayer)
• Bluemix Business Rules
• A subset of ODM ready to use in Pay as you Go approach
• Deploy your decision services in a PaaS
• Based on Cloud Foundry
• RES Console + HTDS + Rule Designer update site

43. Wrap up
• ODM 8.7.0
• Standard for decision services
• Advanced for situation detection with Decision Server Insights
• ODM Standard
• Target stateless decision services
• Versatile platform running on distributed, z/OS & clouds
– Run the same business rules everywhere
• Open to platform combinations:
– ex DC in distributed + DS in distributed + zRES on z/OS
– ex DC & DS in Pure Service + zRES
• Decision Center & Decision Server come with their own
repository and are independent
– DC & RD build and deploy executable rule artifacts to DS
– All execs performed in DC, or RD for dev only
– Testing and simulations are triggered from DC and delegated to DS
43

44. Best Practices
• Prefer 1 shared DC + multiple DS dedicated per env
• Use the branch/merge for handle team collaboration & multiple
releases
• Additional DCs are possible but adding artifact lifecycle mgt
complexity
• 1 WAS Cell per stage env with DS
• Leverage AS cluster for preprod and production envs
• Add DB HA/DR for DC and DS production envs
• Use collocated DC+DS for standalone dev envs
• Make a dedicated simulation env when this workload become
significant
44

45. Best Practices
• Privilege a single RES Console that would be automatically
restarted if a failure occurs
• Choose your RES notif in Decision Server
• JMX notification when RES Console & all eXecution Units are
in the same AS admin scope (WAS cell or equiv)
• IP notif when running on JEE/JSE without JMX federation
45

46. Wrap up
• Tell us if you are interested in new platforms & languages:
embedded, mobile, Javascript in web browser
• Help the Lab by entering RFEs to push for a full RES Console
cluster support
• For more
• ODM topology DevWorks article
• ODM Performance Redbook
46

47. Notices and Disclaimers
Copyright © 2015 by International Business Machines Corporation (IBM). No part of this document may be reproduced or
transmitted in any form without written permission from IBM.
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with
IBM.
Information in these presentations (including information relating to products that have not yet been announced by IBM) has been
reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM
shall have no responsibility to update this information. THIS document is distributed "AS IS" without any warranty, either express
or implied. In no event shall IBM be liable for any damage arising from the use of this information, including but not limited to,
loss of data, business interruption, loss of profit or loss of opportunity. IBM products and services are warranted according to the
terms and conditions of the agreements under which they are provided.
Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without
notice.
Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are
presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual
performance, cost, savings or other results in other operating environments may vary.
References in this document to IBM products, programs, or services does not imply that IBM intends to make such products,
programs or services available in all countries in which IBM operates or does business.
Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not
necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither
intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation.
It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal
counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s
business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or
represent or warrant that its services or products will ensure that the customer is in compliance with any law.

48. Notices and Disclaimers (con’t)
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products in connection with this
publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to
interoperate with IBM’s products. IBM expressly disclaims all warranties, expressed or implied, including but not
limited to, the implied warranties of merchantability and fitness for a particular purpose.
The provision of the information contained herein is not intended to, and does not, grant any right or license under any
IBM patents, copyrights, trademarks or other intellectual property right.
•IBM, the IBM logo, ibm.com, Bluemix, Blueworks Live, CICS, Clearcase, DOORS®, Enterprise Document
Management System™, Global Business Services ®, Global Technology Services ®, Information on Demand, ILOG,
Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®,
pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®,
QRadar®, Rational®, Rhapsody®, SoDA, SPSS, StoredIQ, Tivoli®, Trusteer®, urban{code}®, Watson, WebSphere®,
Worklight®, X-Force® and System z® Z/OS, are trademarks of International Business Machines Corporation,
registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other
companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at:
www.ibm.com/legal/copytrade.shtml.

49. Thank You
Your Feedback is
Important!
Access the InterConnect 2015
Conference CONNECT Attendee
Portal to complete your session
surveys from your smartphone,
laptop or conference kiosk.