Page History

...

Assessment of Workday Technical Session at CU

4/28/2010

...

Synchronization of data

The initial synchronization assessment of synchronization determined that PERSON, CAMPUS COMMUNITY, JOB and possibly LOOK UP tables must be synchronized between Workday and Peoplesoft.  The synchronization of data is necessary to support:

...

Excel spreadsheet of Campus Community data as used Cornell.

...

Architecture/Integration:

• PS and Workday integration: Keep the PS/HR Job and CC tables in tact in PeopleSoft and have 1 way push from Workday to push into PeopleSoft. Details of timing, field to field mapping, and transformations needs to be done in a project to plan out the details of how to. Search match, data deliver extracts, the long list of SQRs, Cobol jobs, ect. need to persist and have access to person data in PeopleSoft.  Changing and sustaining the changes to those PS objects is  prohibitively expensive and risky.  So, we would keep a headless HR/Payroll PS system to support those SQR, data delivery, jobs, etc. 
• PS Search match: HR's use of  search match may need to be done in PS or called / used by Workday since Workday wouldn't have the Student and Alumni records, or would it? If manual search match needed manual intervention (based on teh value returned) the hire process would be stopped to force manual  setting of the match.
• Workday needs of PeopleSoft for hiring. Workday hire process needs the following from PS:
  • call PeopleSoft's search match tool (or have the search match be done manually)
  • call PeopleSoft's EmplID generator

C. Small things:

• EMN (Emergency Mass Notification): EMN isn't on the rough interface list. Right now it uses the UNified Directory Feed AND direct reads. (Chris Grippin knows exactly how that works.) The end result is that the  EMN DB is updated nightly and the external vendor EMN systems (Hyperreach and AlertNOW) are loaded from it every morning.
• User machines: Flash players would need to be upgraded periodically for all users of Workday.

D. Architecture/Integration Stuff:

• Workday uses object models in place of the RDBMS model.  Data is stored in memory. 
  • Need to consider performance, persistence and fault tolerance
  • Tools for access data
• Central integration tool
• Workday ESB was CapeClear; Workday ESB Studio (Eclipse)
• OODB
• XML blobs stored in DB tables
• Do we need to be concerned about performance and persistance and fault tolerance given they don't have all the massive RDBMS research and years of improvement and perfection behind it  that, for example, Oracle has?  (No: they do have tables - just abstracted to an object models.)
• Is this semantic web/ontology object model?  Can we use other tools specific for this to get at data? (It looks like an ontology model. And, no, for acces it looks like you have to go through their object model via web services.)
• WE NEED A CENTRAL INTEGRATION TOOL (e.g. webMethods 8 or Oracle SOA Suite) - that will make this a heck of a lot easiersuite). 
  • Avoid
  • We should use a central tool to receive notifications from Workday or otherwise we'll be going point to point and having to install "External Systems" into Workday to integrate with, which becomes a maintenance hassle in Workday
  • Can we just create an ESB bridge?
  • An Enterprise Asset repository could help to organize and show all of the Workday web services which we could apply policies to
  • integrations and all associated maintenance and coordination that would be associated. 
  • Create an Enterprise Service Bus bridge/repository to support a single view of all Workday web services where policies could be applied
• Access to Workday developer community site
  • Review Workday
  We need access to their developer community site and we need to poke around through their
  • web service list, especially the 'Integration'
  ones
  • web services with the
  interesting
  • high level 'cloud' service integrations.
  • SPML - http://en.wikipedia.org/wiki/Service_Provisioning_Markup_Language
  • SAML/Shibboleth support
  • 'cloud esb offering' = client downloads the tools and does their own integrations to be validated and deployed by Workday in the cloud. Two clients are doing this in 'beta'.  Not really meant for
   customers
  • customers that have their own integration tools, such as webMethods or SOA suite.
  INtegrations
  • Integrations with our systems:
    • Kronos if it was software as a service: no problem. 
    • Kuali Finance: we'd have to track down all the mapping of their CoA representation.
  We
  • Cornell should
  get serious about
  • consider a portal
  - we're going to need one
  • to aggregate
  all of these
  • different "Inboxes" from the different systems.
  • Could we have Inbox items in Workday create notification items in Cynergy that link out to Workday for a single Inbox?  This could easily be done with Events/Notifications from Workday and webMethods/SOA Suite to recognize and create a notification item in Cynergy
  • Web Services: https://community.workday.com/api

E. Reporting and service generation:

...

• data fit gap -  before or after The Project starts? if we are a Strategic Partner we would be 'in the system' before hand and understand the tool, so probably this fit gap would be done during the partnership and before the project officially starts.
• CU project roles defined by Workday:
  • see Lyman's notes of the formal role definitions and Workday's normal support protocol 
  • Business analyst: power user
  • Tech analyst: tech part of integration, data extraction, security
  • PM
  • workday administrator: administer users and roles and groups. support escalation.
• ALSO, as probable prerequisites:
  • integration standards, SOA tools like Oracle SOA Suite or an upgraded webMethods
  • clear vision on reporting and datamart goals
  • prep/set up tier one support
  • figure out the realistic timing with Kuali Finance

B. Big, Early, Tentative Conclusions:

• PS and Workday integration: Keep the PS/HR Job and CC tables in tact in PeopleSoft and have 1 way push from Workday to push into PeopleSoft. Details of timing, field to field mapping, and transformations needs to be done in a project to plan out the details of how to. Search match, data deliver extracts, the long list of SQRs, Cobol jobs, ect. need to persist and have access to person data in PeopleSoft.  Changing and sustaining the changes to those PS objects is  prohibitively expensive and risky.  So, we would keep a headless HR/Payroll PS system to support those SQR, data delivery, jobs, etc. 
• PS Search match: HR's use of  search match may need to be done in PS or called / used by Workday since Workday wouldn't have the Student and Alumni records, or would it? If manual search match needed manual intervention (based on teh value returned) the hire process would be stopped to force manual  setting of the match.
• Workday needs of PeopleSoft for hiring. Workday hire process needs the following from PS:
  • call PeopleSoft's search match tool (or have the search match be done manually)
  • call PeopleSoft's EmplID generatorCornell should consider a portal to aggregate different "Inboxes" from the different systems.

C. Small things:

• EMN (Emergency Mass Notification): EMN isn't on the rough interface list. Right now it uses the UNified Directory Feed AND direct reads. (Chris Grippin knows exactly how that works.) The end result is that the  EMN DB is updated nightly and the external vendor EMN systems (Hyperreach and AlertNOW) are loaded from it every morning.
• User machines: Flash players would need to be upgraded periodically for all users of Workday.

J. Action items - things that need more conversations

...