© 2015 IBM Corporation0

Best Practices: BPM Implementation, Migration and Upgrade

Allen Chan, IBM BPM Lead Architect – Install, Config and MigrationBrian Petrini, IBM BPM Technical Product ManagerJerome Boyer, IBM Software Services, Implementation Methods

Agenda

• BPM 8.5.6

• Upgrade Approches

• Migration Approches

• Top Practices

1

Act in context with data Drive simplicity and speed with cloud

Accelerate customer engagement

Highlights of What’s New in Business Process Manager v8.5.6 & Business Monitor

§ Watson integration samples

§ Embedded content store

§ Embedded rules

Product Foundation

§ BPM Developer Center

§ Federated Portal• Seamlessly blend tasks from

multiple BPM servers across versions (v8.0+)

§ Asset to Isolate Process Applications (start, stop, move)

§ Business Monitor updates§ IBM PureApplication®System

pattern released§ Expanded operating system

coverage§ Dashboard customization with

Rapidly Adaptive Visualization Engine

§ BPM on Cloud• Tiered Pricing• Data center support in

Japan and Hong Kong

§ Workflow Service on Bluemix

§ Mobile Responsive Portal

§ Case Management • Case Linking

§ Enhanced FileNet Content Manager support

§ Responsive Coaches

§ Click to create Worklight projects

§ REST API for custom mobile application development

Key: New feature Previously released feature

WPS Upgrade & Migration Paths

From ToVersion EOS BPM BPM BPM BPM BPM BPM

751x 800x 801x 850x 855 856WPS 602 09/2010

WPS 610 04/2013 Yes

WPS 612 09/2013 Yes

WPS 620 04/2014 Yes Yes Yes Yes Yes Yes

WPS 700 04/2015 Yes Yes Yes Yes Yes Yes

migrationupgrade

For WPS 602 and 61x, we currently do not provide a direct upgrade path for runtime migration (i.e. preserve existing process instances) to BPM 8xx. However, customers can still use IID 8xx and manually update the applications to get it working on the latest BPM level, and then use the “drain” approach (see later charts for details).

WLE Upgrade & Migration Paths

From ToVersion EOS BPM BPM BPM BPM BPM BPM

751x 800x 801x 850x 855 856TW 61x 09/2013 Yes Yes Yes As

neededAs needed

As needed

TW 62x 09/2013 Yes Yes Yes Yes Yes YesWLE 71 09/2013 Yes Yes Yes Yes Yes YesWLE 72 04/2016 Yes Yes Yes Yes Yes Yes

migrationupgrade

BPM Upgrade & Migration Paths

From ToVersion EOS BPM BPM BPM BPM BPM BPM

751x 800x 801x 850x 855 856BPM 750 09/2016

expected

Upgrade Yes Yes Yes Yes Yes

BPM 751 09/2016expected

Upgrade Yes Yes Yes Yes Yes

BPM 800 09/2017expected

Upgrade Upgrade Yes Yes Yes

BPM 801 09/2017expected

Upgrade Yes Yes Yes

BPM 850 n/a Upgrade Upgrade Upgrade

migrationupgrade

6

Migration Improvements

Infrastructure migration/updateIn 8.5 we drastically simplified the infrastructure, improving the standardization and as a result improved the testing coverage. We went from 9700 permutations to about an order of magnitude fewer. Likewise we went to a central configuration file (BPMConfig).To help with migration we have created config extraction tools that take from older versions, display the configuration graphically for modification, and allow creation of new environments from this file.For ifixes and fixpacks, we have been working on simplifying the ifix updates so that include the dependency trees, making applying them simpler.Migration checklist -­ we now include a migration checklist to check for the infrastructure.DB clone -­ since 8.5.5 we support DB cloning for migration. This greatly reduces risk as customers can migrate to a cloned DB and if there are any issues they can just point to the original DB.

Fixpack strategy -­ Since 8.5.0 we have been including all fixes in the next feature release. This increases quality for our customers as we are reducing the number of code streams that we have to support and test, allowing us to be more thorough testing.

7

Migration Improvements

Application migrationWe have been stabilizing the programming models over the last 4 years, making fewer changes in each release. As a result, application migration is simpler for customers moving from later releases.

App-­by-­app migrationIn 8.5.6 we will introduce as a services asset the app-­by-­app migration. This will give business more flexibility as they won't have to migrate the entire infrastructure, but rather could focus on one or two process applications that need the latest infrastructure.

Instance MigrationWe continue to improve the performance of instance migration which will allow for shorter time windows when applications are updated and older instances are migrated to the latest snapshot. In the latest release it is an order of magnitude faster than in 8.5.6 due to parallelism in both local threads and multiple nodes.

8

18 month entitlement

LicenseWe recognize that the SWG standard of 90 day dual entitlement may not suffice for large BPM deployments doing BPM Version to Version system migrations with long running processes and in this case have a pre-­approved, 18 month extended migration agreement that can be offered. Link to information: http://www-­01.ibm.com/software/integration/business-­process-­manager/library/entitlement-­migration-­bpm/

9

Reducing the need for migration

• Upgrade strategy -­ Since 8.5.0, we have followed an "update only" constraint on every new 8.5 release. This has resulted in upgrade only infrastructure since 8.5.0 (June 2013) that will continue until we reach BPM 9. This is at least 3 years of upgrades only. Compare that to the previous years where we forced a migration each year (every release).

• Federated API/Portal -­ In 8.5.6 we are introducing a federated portal that aggregates the information from cells of different BPM versions. This is key to our strategy going forward as we release new versions. This way you can let their existing applications and process instances drain from older cells and start new processes in the new cell. This would greatly reduce the need for application migration.

Upgrade Approaches

10

Upgrade Rules of Thumbs1. You can use a “rolling upgrade” methodology to upgrade your BPM ecosystems.

a. In-­place Rolling Upgradeb. Side-­by-­side Rolling Upgrade

2. Do not upgrade your Process Center (Dev environment) until you have at least proved that the upgrade is working in your QA environment.

3. The version of Process Designer and Integration Designer must match the version of the Process Center.

4. The version of Process Center and Process Server must match in order for the Process Server to be connected as “online”.

5. An application that you developed using an older version of the BPM product can be deployed to run on a newer version of BPM as long as it is not using features that have been removed.

6. We strive to maintain API compatibility in BPM mod and fixpack releases. 7. In BPM 85xx, we enabled the support of online rolling upgrade:

a. BPM 8500 Process Designer and Integration Designer to connect to BPM 8501 of Process Center and Process Server (for debugging).

b. A BPM 8501 Process Server can connect as “online” mode to BPM 8500 Process Center.

c. The purpose to facilitate debugging of upgraded application and allow a more gradual roll out of the upgrades.

Process – In-­Place Rolling Upgrade

startCertify PS<Test> end

Certify PS<Staging>

Certify PS<Prod> Certify PC

In this procedure, we will upgrade PS first.. From <Test> to <Prod>, and finally upgrade PC.

Pros:1.Upgrade and certify one Process Server environment at a time in an orderly fashion.2.Upgrade PC last as we want to ensure we can continue to provide fixes to PS running at current version.

Cons:1.Upgrade PC last means developers cannot utilize new features until the entire eco-­system is upgraded.2.With the exception of 8501 (Fuji), any other upgrade would force the PS to go offline to the down-­level PC, thus requiring offline deployment until the PC is upgraded.

We should always take a full backup of your environment before the upgrade, this allows up to restore any environment during this period in order to deliver a hot-­fix of your application to your <Prod> environment before your <Prod> environment can be upgraded.

Process – Side-­by-­Side Rolling Upgrade

startSide-­by-­side“upgraded”

PC

Certify andRe-­target PS<Test>

Certify andRe-­target PS<Staging>

Certify PS<Prod>

In this procedure, we will setup a new “upgraded” PC side-­by-­side, and then proceed to upgrade each of the PS enviroment.

Pros:1.An “upgraded” PC is available immediately for new development and tests2.Customers can certify new product version on a per-­application basis without impacting existing development and test.3.All Process Server environments can maintain “online” status all the time.

Cons:1.Setup a side-­by-­side “upgraded” PC will require additional IT resources and may incur additional licensing cost.2.May require more work if the customers’ configuration is not well documented.3.Depending on the approach to setup the side-­by-­side PC, one will lose existing “playback”instances data.

Sunset old PC end

Managing fixpack upgrade downtime

By performing some upgrade tasks in parallel, we can reduce the time it took to upgrade. In this example, we are upgrading to 7.5.1.2.

Upgrade from 7.5.1.x to 7.5.1.2 Time

• update Installation Manager• backup configuration

1 – 2 min (in parallel)

• update Deployment Manager and Nodes using a “staggering”approach with 10 min delay between each node.

60 min

• upgrade clusters• upgrade database

10 min

Total 72 min*

•Time is taken based on a test system with 3 nodes. The actual time will depend on a number of factors such as disk access time, network latency, CPU speed, etc.• For upgrade from 7.5.0.0, you can expect more time is needed for updating the individual node.

Migration Approaches

15

Engage IBM EAS and ISSW for a migration assessment and assistant

Plan your migration

16

Plan your migration

1. Understand YourReqts and Environment

2. Migration Assessment

Team Regular Communication

3. Identify Project Teamand Project Plan

4. Develop MigrationStrategy and Documents

7. Test Migration and Recovery Plan

5. Migration and TestYour Applications

6. Clean up Source Environment

8. Go Live Planningand Execution

Landscape

1-­ Current product version used to support existing production applications

CurrentProcess Server(Test/ Staging/ Production)

CurrentProcess Center

2-­ New applications are developed on new version.

New DevProcess Server

NewProcess Center

New Process Server(Test/Staging/Production)

1

2

4

3

3-­ Export/import Toolkit for refactoring

4-­ Migrate artifacts and/or business data

5-­ Deploy new and migrated apps 5

Migration Approach

Drain -­ Application migration and “drain” existing instances • Let existing instances in V-­old run to completion, start new instances in V-­new system.

Milestone Transfer -­ Transfer process state mid-­stream using custom logic to new version.• A variation of the “Drain” approach.• Let existing instances in V-­old run to a designated set of business milestones, start new instances in V-­new system from those milestones.

Runtime Migration -­ Application migration followed by Runtime migration • Once ALL applications are working in V-­new, convert the existing database to make it compatible with V-­new in one shot.

What to Migrate?

Pros ConsArtifacts Only Migration(Drain orMilestone Transfer)

Start with a clean database. Leave messy data behind.

Parallel production environment allows for app-­by-­app migration and no production downtime.

Process history are not transferred to the new system.

Parallel production environment requires additional maintenance and resources.

Business Data and Applications Migration(Runtime Migration)

Source environment applications and data are migrated to the target environment.

Process and human tasks can start in the source environment and complete in the target environment.

Bringing over all data depending on size and complexity can increase migration risks which requires additional testing.

Downtime required. All applications must be ready before you can start migrating the system.

Process Center Migration

Observing that Process Center contains “playback” instances only, there is really no business needs to migrate “playback” instances to the new product version. Based on this assumption, we are simplifying the Process Center migration to application-­only migration.

• Setup a new PC target environment with new database.• Migrate individual application artifact by exporting “active” snapshots from source environment to target environment in chronological order.• Runtime data (instances, tasks, tracking groups, etc) and offline server deployment information will not be migrated.

Advantages:• One can setup Process Center right away and start working on application migration.• Application can be moved to new product version one application at a time.• Existing V-­old Process Center is still available to handle fixes for production system.• No downtime for Process Center.

Not applicable if Process Center is notused in your system.

Migration Enhancement

21

BPM 8.5.5/8.5.6 Migration EnhancementImprove migration robustness, ease-­of-­use and planning• Revised documentation with enhanced interactive migration guide and guidance on migration methodology to better guide customers and services on how to plan their migration project.

• Migration Pre-­Validation Tool + Post-­Validation Health Center• Pre-­check and report migration potential failures• Save cost of migration late phase failure, recovery and redo• Post-­Validation via BPM Health Center, speed up target environment health check

• Easier environment setup via Configuration Migration Tool• Migration paths support with a target environment that is set up with about 400 source-­environment basic properties around database, security, and the most important performance parameters to the client’s environment.

• Reduce about 50% post-­migration actions on properties• Separate tool can export/import WAS application level configurations which are not owned by the BPM, like: data source, auth-­alias, SSL settings

Speeding up migration • Quicker migration via multi-­thread enablement

• Migration from BPM v7.5.1 migration shows 2x ~ 3x improvements• Migration from TW v6.2 migration can see up to 20x improvements

22

Interactive Migration Guide• Help you determine the expected document that matches your migration scenario, save your effort to search infocenter and navigate between different topics.

23

Two steps wizard

Validate source environment before migration• We introduced migration pre-­validation tool to help you find potential issues before real migration, and what you should take care during migration

• Validate current environment to make sure it’s ready to do migration

• Read required information that will be used in latter migration steps

• Show error if it’ll block migration, or the source environment isn’t in the expected status

• Show warning if you need to take care before or after migration• Show warning if there is some big number of data will have performance impact during migration

24

Validate source environment before migration• Report sample 1 for migration prevalidation

25

Validate source environment before migration• Report sample 2 for migration prevalidation

26

Understand configuration migration• Source environment information

• Map to the supported target based on what your source environment was.• Make sure it’ll reuse old database on the target.

• Security• Federated LDAP• LTPA• File registry

• Performance tuning• Customized XML files (e.g. 100Custom.xml)

• Some properties will be moved to WCCM• Keep remaining customization and copy to each node on the target

• Business Process Choreographer• Business Flow Manager• Human Task Manager

27

Understand configuration migration

28

Source Target

Move configuration

Edit the exported properties file using Configuration Editor

BPMConfig -­migrate BPMConfig -­create

• WebSphere Process Server 6.2.x or 7.0.0.x

• WebSphere Lombardi Edition 7.1 or 7.2

• IBM Business Process Manager 7.5.x or 8.0.x Express/Standard/Advanced

• IBM Business Process Manager 8.5.6.0 Express/Standard/Advanced/AdvancedOnly

Understand database upgrade• For Standard database: Process Server and PDW database

• DBUpgrade will cover both schema update and data transform• Tune the script to get better performance (thread or batch size)

• For Advanced database: Common/BPC/BusinessSpace• upgradeSchemaAll will run all required upgrade SQL files• upgradeSchemaAll will also run the initialization SQL for newly added capability if any

• Support to test and validate migration using cloned database• BPMMigrate will update the topology information in the database

• Import SIB messages to the target• Recreate WAS scheduler tasks

29

Understand database upgrade

30

Do other configuration customizationEstimate migration window...

Source

TargetCloned

Target

Cloned ClonedClone database

BPMConfig –update -­dataSource

Test database upgrade using cloned database, and finally retarget your current environment to the original database to do the last run.

Test migration against cloned databases

Understand database upgrade• Performance improvement on database upgrade

• DBUpgrade have much performance improvement, and you can add more threads to handle the transform of large number of instance and task

31

Wang Lei ok, thanks 4:53:22 PM

Cleaning up before migrationThe more data we have in the BPM system, the longer it will take

migration to run. So it is important that before we run migration, remove information that are not required anymore in the new system.

• ProcessInstancesCleanup command to remove “completed” process instances.

• Performance Data Warehouse prune command for removing PDW data.

• BPMDeleteDurableMessages command to remove durable events that are no longer needed.

32

BPM Health Center• Check the health status of the deployment environment after migration, should be the first step to validate migrated environment before other planned testing

33

App-­by-­App services asset for BPM StandardSupport selective migration of applications runtime data1. Selective migration

1. Only move certain applications2. Only move the data which need keep in the new environment by the time range3. Only move the system data like users, groups, user-­group-­relationship, user attributes, etc

2. Splitting of deployment systems1. Refine the deployment design2. Scaling out application

3. Database vendor conversion -­ other databases move to DB2

What this is not intended for: 1.Temporary move of applications for the isolation and then moved back2.Massive restructuring of the BPM environments3.Move applications freely among different BPM environments4.Move advanced data (BPEL)

34

App-­by-­App compare with runtime migration

Pros ConsApp-­by-­app Migration

1. Migrate one BPM Standard application at a time to the new system to reduce migration risk.

2. Support database conversion to DB/2 from Oracle or SQL Server.

3. Support limited migration undo.4. Enhanced Pre-­validation before

migration.5. Minimum system downtime (restart

target system after migration, stop event manager during migration)

1. Support BPM Standard only. Advanced content is not migrated.

2. DB2 for z/OS databases are not supported.

3. Available as Services Asset only at this point.

Business Data and Applications Migration(Runtime Migration)

1. Support both BPM Standard and BPM Advanced.

2. Source environment applications and data are migrated to the target environment.

3. All historical information is preserved

1. Bringing over all data depending on size and complexity can increase migration risks which requires additional testing.

2. Full Downtime required. All applications must be ready before you can start migrating the system.

Migration Top Practices

36

IBM Services Migration Project Roadmap

Goal:• To provide a high-­level

understanding of migration options;;• Capture the information that is

relevant to the migration• Recommend next steps.

Steps: • Review current infrastructure &

project goal

Input:• Migration Discovery Questionnaire

Output:• A documented understanding of the

current infrastructure;; a commitment by the client to invest their time in a Migration Assessment/Pilot

Goal:• To provide ROM estimates for

migrating selected process applications and service integrations in a ‘like for like’ fashion from the current environment to the target environment

Steps:• Process Application business and

functional review• Process App. architectural review• Process App. source code review

Output:• High level migration approach• ROM estimation

Goal:• To migrate selected process

applications and service integrations from the current to target environment

Steps: • Install and configure selected

environments and tools• Migrate code to the new

environment• Perform testing & defect

resolution

Output:• Migrated applications and

environment• Team enabled

Discovery CallDuration: 2 hours

Discovery WorkshopDuration: 1 to 2 daysNo charge

ImplementationDuration: varies, depending on scope and complexity

Questionnaire: 30 questions to discover the potential scope

• Version• Runtime• Application• Operational model• Test

• Converged with WAS migration questionnaire

38

Migration Workshop

Goals Review the migration baseline Define application and asset inventory.Identify customizationsReview current physical architectureAssess Hardware / Software requirementsReview deployment strategyDefine migration validation strategy

Define migration approach Determine runtime migration approachRecommend solution architecture.Recommend BPM topologyIdentify key improvement opportunities enabled by new/enhanced product features.Define staffing skills needed

Determine next steps Workshop report with recommendations and findingsRough Order Of Magnitude estimate and project approach (WBS)Define the best migration approach

Who IBM Migration Specialist<IBM BPM Developer>IBM Client Partner

IT ArchitectBPM DeveloperProject manager

Format 1 to 2 days No charge39

Top Practices for Successful Migration• Minimize Refactoring – we are often tempted to make significant changes to the applications as part of a migration project. This can lead to un-­intended delay in projects or make it impossible to migrate runtime data.

• Having a comprehensive regression test plan, including non-­functional tests such as stress and performance tests, can help eliminate surprises in the project.

• Review and playback often and regularly with business and IT stake holders, this avoids last minute surprises such as user experience expectation, security concerns, etc.

• Use good quality data for in-­flight migration testing (UAT or production databases). Database from development environment contains a lot of development “noise” which causes problems

40

Top Practices for Successful Migration• Test database upgrade using cloned database of production environment, estimate migration windows and verify the migrated environment

• Carefully test migrated instances for each Application. Some problems can be revealed only with specific development patterns unique to specific process application (e.g. serialization changes between TW6 and BPM8 affected event correlation)

• There is no fixed formula to estimate the time up front as the migration depends on a number of factors such as number of process instances, tasks, users, groups, durable subscriptions, tracking groups, size of your data and execution context, etc.

• Applications should be upgraded and running correctly in target system at least 2 months before go-­live date. Migration and Performance testing should start as soon as possible, not just a couple weeks before go-­live.

41

Other special considerations• Account of changes in security model early – want to switch to LDAP from file-­based repository?

• Account for non-­standard cluster configuration if you’re not following the IBM recommended golden topology for your setup.

• BPM + Monitor. If your source BPM environment is augmented with Monitor in the same cell, but in BPM 8550/8560, we don’t support BPM and Monitor in the same cell any longer, you have to follow two separate procedures to migrate BPM and Monitor to separate cells on BPM 8550/BPM 8560.

42

Other special considerations• Test the cases that some instance arrives at an activity that waiting for some event (UCA), make sure the messages can still be consumed after migration.

• If you’re migrating from multiple deployment environments, you need to do the migration procedure for each of your deployment environment.

• Port number maybe changed after migration, you need to update them manually or use the new ports.

• BPMMigrate command can rerun if it doesn’t import SIB messages yet or you can clean SIB tables before the second run.

• Backup fileRegistry.xml if you want to enable LDAP after migration, or will meet with some errors when try to access the document tables.

• We don’t support the migration of IID UTE

43

Additional In-­depth BPM Sessions• 1931 IBM BPM Upgrade and Migration Roundtable – in Coral C• Tue 9:30-­10:30, • Wed 17:30-­18:30, • Thu 10:30-­11:30

44

Meet other clients and learn about Expert Access Services for on-­demand enablement and consulting on development, migration and infrastructure topics.

Wednesday, February 25, 2PM-­3PM Jasmine H, floor 3, Mandalay Bay

Please RSVP to La Donna Quinn – lquinn@us.ibm.comPlease show this invitation on your Smartphone at the reception entrance, or print and

bring with you to gain entrance.

Migration References• Planning a migration to the latest version of IBM BPM and IBM Business Monitorhttp://www.ibm.com/developerworks/bpm/library/techarticles/1502_sharma/1502_sharma.html

• Estimating the efforts for IBM Business Process Manager migrations –why it’s not easy!https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/bpmmigrationsizing?lang=en

46

Questions?

Notices and DisclaimersCopyright © 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 beenreviewed 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.

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®, urbancode®, 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.

Thank YouYour Feedback is

Important!

Access the InterConnect 2015 Conference CONNECT Attendee Portal to complete your session surveys from your smartphone, laptop or conference kiosk.