Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Assessment of Workday Technical Session at CU

4/28/2010

Overall Assessment:

Technically there appears to be no showstoppers that would prevent a Workday solution.  Through various detailed discussions it was concluded that there are technical and business process solutions to mitigate any areas that would be "broken" as a result of moving Human Resources, Payroll and Benefits from Peoplesoft to Workday.

Synchronization of data

The initial synchronization assessment determined that PERSON, CAMPUS COMMUNITY, JOB and possibly LOOK UP tables must be and can 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 Considerations:

  • All Workday associated hardware is housed and supported by Workday.
  • 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 to access data
  • Central integration tool (e.g. webMethods 8 or Oracle SOA suite). 
    • Avoid point to point 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 web service list, especially the 'Integration' web services with the 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.
  • Cynergy considerations:   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 CynergyWeb Services: https://community.workday.com/api

Reporting and Service Generation:

  • ReportsReport generation is dynamic, scalable, customizable and secured:
    • 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. 
    • Using reports - as a human or as an app - requires privileges. Data relevance is based on privileges.
  • Web Services are dynamic, customizable and secured:
    • Using web services
    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 privileges. Data relevance is based on privileges.
    • Searching capabilities exist.
    • External Systems have their own IDs that register themselves as clients.
    • Workday authorizes the system and the user of the external app to:
      • allow use of the service and
      • 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, picked pick up, service called to import it, or upload it manually
    • Ability to 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 Error descriptions are 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 Use these types of tools for governance and standards. few do.
    • We would make a report of teh Report of the service enabled reports and load the SOA suite repository so they aren't manually synchedsynced.
    • We could have all clients of Workday call Consider calling a service in soa Oracle 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).

...