You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Assessment of Workday Technical Session at CU

4/28/2010

A. Synchronization of data

The initial 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:

  • single Person records (no duplicates), 
  • support Search/Match functionality,
  • single key identifier for all People,
  • single point of data retrieval for satellite systems (ie: University ID Card),
  • determination of overall status and affiliation of a person within the University,
  • consistency of setup table values across systemsDiscussion points to be considered would be timing of synchronization (real time vs. batch), mapping/transformation of values between systems and system of record.

    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 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 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 easier
    • 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
  • We need access to their developer community site and we need to poke around through their web service list, especially the 'Integration' ones 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 that have their own integration tools, such as webMethods or SOA suite.
  • 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 should get serious about 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:

  • Reports:
    • You can define calculated fields at report time.
    • Report writing lets you make reports based on the access you have. Then save, schedule, share, or make as a web service. 
  • Services:
    • Making web services requires specific permissions.
    • You can search through reports and see which are shared and which are web services.
    • Using the services and reports - as a human or as an app - requires privs too. You get the data relevant to your privs.
    • External Systems have their own IDs that register themselves as clients.
    • Workday authorizes the system and the user of the external app to a) allow use of the service and b) get the right data back.
  • EIB: outbound flat file generation, select, transform (XML to CSV, or custom XSLT), ship to an SFTP site, encrypt if you want, run or schedule
  • EIB: for high volume loads...
    • SFTP the file, which is a loaded templated spreadsheet, and then they pick it up and call a service to import it, or upload it manually
    • set  basic error handling manually in defining the upload - # load error limits, validate only load... : errors are based on object validation
    • the error description is added to each error row that failed. 
  • Notifications of automated integrations:
    • VERY extensive integration completion / status reporting - content, trigger condition, recipients, groups, subject, content/body, conditions and rules, with attachments of the file, etc.
  • All events and updates publish the object id, but not the employee id. Any listener of the service (e.g. at CU) has to call back using the object ID to update and/or get more info.
  • Oracle SOA Suite and webMethods:
    • They would like to see more clients using these types of tools for governance and standards. few do.
    • We would make a report of teh service enabled reports and load the SOA suite repository so they aren't manually synched.
    • We could have all clients of Workday call a service in soa suite and use CUWA and then call Workday without CUWA. This is bus to bus (I think - SL).
    • Use if SOA Suite would enable tracking of the use of the services of Workday. Workday doesn't provide service use info. Those usage stats could then tell us which services are actually being used so we  know what to worry about when one side or the other changes (i.e. impact analysis support).

F. Conversion and mapping:

  • job, compensation, worker  histories would normally be inserted
  • benefit history: might be included under compensation. Workday will need to clarify that. Benefit history is needed for IRS audits.
  • there are 'set limits on historical information brought forward'
  • 6 months needed. They have basic estimates and a framework / generic plan for a conversion effort.
  • Process: we would have to put data into their spreadsheet templates.  They have a very specific sequence to go through to load the system - set up tables and then the objects.
  • Resources needed: 1 or 2 tech people for the deployment, so says Workday.

G. Security

  • two data centers and a near real time 2nd site (atlanta)
  • keys next to encrypted data but encrypted differently
  • See their 'Security INtegrations' slide 
  • Role and hierarchy is the basis row level security. The security data could all be exported in a report.
  • all updates are logged with a timestamp and a user id. All attributes - not just rows.
  • dual factor authentication? no
  • 'direct pipes / private networks?' no. it's on the internet.
  • user accounts can be tied to a particular authenN system - as in delegated single sign on.
  • userID generation: Workday would publish the event, CU idmgmt would listen, pick it up, call back with the event id, and provide a netid to Workday to store with the person as well as either a) telling peoplesoft directly OR b) letting Workday update peoplesoft's external system table.
  • audit logging doesn't keep the IP address.
  • Workday cannot lock down by IP address.
  • timeouts for inactivity by groups and functions: They don't know and will be checking.
  • group management: it is all done in Workday. They don't know of the feasibility in using eternal groups.
  • people can be in multiple functional domains.
  • row level access is based on teh org structure you are in.
  • Security group management: Too much to list. It is just best to see the demo. There will have to be many management conversations about how to manage groups, grant them rights and assign people to them.

H. Data marts

  • current HR/Datamarts are used for non PS HR apps and reporting partly because access to Peoplesoft is too difficult and acceptable timing wise (a day late).
  • advantage of using Workday reports and analytics: 
    • current data
    • can drive in immediately and take action
  • potential problems of using Workday reports and analytics:
    • more people have datamart access than peoplesoft access now
    • longitude data combines data with other info 
  • reports:
    • specialized reports might still be from the datamart, but note that analytics are available right in Workday and most if not all reports would come from there.
  • Non PS HR apps using the datamart now:
    • any specialized apps that might be needed would go to Workday if possible
    • some might not: CCTS, LARS
    • QUESTION: what apps would be left after Workday is deployed completely done?
  • To do (in an analysis project): When we see what is really left (as in needed for reporting) after using Workday for reports and the left over-and-not-covered-by-Workday HR apps, then we know what a new hr/payroll datamart looks like.  For those we either a) make new extracts from Workday to feed the datamart, or b) load PS HRand keep pulling from there.
  • Can Oracle SOA Suite help with integration to Datamart and OBIEE for a more powerful/less complicated process?

I. Deployment notes

  • 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

J. Action items - things that need more conversations

  • Reporting - HR/Payroll DM future vision: How much of the current HR reporting needs would be done directly from Workday, and how much would be done from the HR/Payroll DM and other DMs?  This would have to be figured out during analysis. It is probably not a 100% replacement, and if we are feeding PS HR/Payroll then that's ok, the warehouse continues to be loaded as it is today.

  • Developer Network: Get access to the developer network [

    http://www.Workday.com/resources/developer_network.php] : Poke around the integration services and see what questions come up. Some of them sounded immensely powerful (clear cloud services or something to that effect).
  • Student Employment process -  talk through options:
    • a. bulk periodic upfront load of students into Workday. That adds a lot of students to the HR system that aren't employees just in case they get hired. we'd have to walk through the scenarios of the student record changing in PS and also changing in Workday.
    • b. call PS on demand during a student hiring process (how would they identify a student in Workday if the data isn't there?)
    • c. REDO SES by building a custom front end that hits both PS services AND Workday services to hire/change student employees. 
  • WSB (Workday Service Bus) fact: is only for Workday, not for local deployment or even cloud ESB deployment - just rolled this out in the cloud too
  • Student employees: Student employment uses a replication of job data. Workday needs PS's Student's person record when a student becomes an employee. Those Students becoming an Employee will need to come from PS and be updated by Workday, as opposed to normally employees who are created in Workday.   
  • Use cases: We need to walk through the set of major and essential use cases of people and jobs and describe responsibilities of the respective system to support the business processes.
  • Diagrams: We need to diagram use cases showing specifically which data is going which direction for what events in each major BP.
  • EmplID: Needs to be created uniquely once from PeopleSoft. If Workday makes people records the EmplID needs to maintain that uniqueness.
  • Other systems using person data: What other systems require person data? COLTS and KRONOS and data delivery.  Do you need to change them or does keeping them
  • BP Impacts: Will need to push data from Workday into HR PeopleSoft CC data otherwise the guts of PeopleSoft will have to get ripped out - Assuming we turn off all business processes in HR PS that would update CC data, are there other BPs in other parts of PS that would update this data - i.e. would we have to back fill from CC data into Workday? - Workday doesn't have tables, just objects, that have to be transformed and kept in sy
  • SOA Suite and CUWA on webservices: 
    • We might need a waiver or change in our CUWA authentication scheme in order to use vendor supplied services (user generated or Workday supplied).
    • SOA Suite or Webmethods and Workday: would we want to force all calls to Workday to go through SOA Suite or WebMethods for CUWA and better governance and of it call Workday and be in the middle?  Seems to have many benefits. List them and add this to the case for SOA Suite.

Notes from Meeting with Aaron, Steve, Karel, Vicky 5/6/2010

Web Services - use Workday webservices to integrate with PS.  We would orchestrate the integration using out of box Workday web service functionality.  Event notification vs batch.

Historical data conversion - how much data needs to be converted?  What is end result impact?

Population of employees in PS - all employees, partial load?

Population of students in Workday - all students, partical load?

Population of data into PS - data elements, historical?

How much linkage is there between HR datamart and "other" datamarts (student, CR etc)?  This will drive the sizing of the datamart.  How much transformation of data is needed? 

  • No labels