Ancillary systems that manage business processes necessary outside of Workday will be “kept”; to continue operating after the Workday implementation, many will need updated data integrations. It is also an opportune time to evaluate the long-term viability and security of these systems and consider appropriate actions to manage risks.
Following are the key steps for “keep” systems in the roadmap to Workday implementation on July 1, 2024:
Step 1: ASP work planning and prioritization
ASP business analysts reach out to all schools, colleges, institutes, and divisions (SCIDs) with a link to a spreadsheet, the purpose of which is to collect additional information on each specific system to help with ASP planning.
Timeframe: January 2023
Step 2: Integration recommendation
Any system that integrates with the current HR or financial system will require Workday data in the future. The goal is to identify a modern integration method that provides the necessary data.
Timeframe: February to July 2023
Step 3: Security review
The Office of Cybersecurity conducts security assessments of most “keep” systems. Risk Executives review the findings and determine appropriate actions if necessary.
Timeframe: February 2023 and ongoing
Step 1 addresses all “keep” systems belonging to a campus unit at once whereas Steps 2 and 3 are done system-by-system, one at a time. Campus units will iteratively go through Steps 2 and 3 for each “keep” system they have.
Step 1: ASP work planning & prioritization
Information collection
Primary technical contact or business contact for the system receives a spreadsheet listing all “keep” systems and 11 questions, many that require selection of one answer from several choices.
Analysis
Responses will be used to plan and prioritize the work in subsequent Steps 2 and 3.
Next step
Work on Step 2, integration recommendation, will start for higher priority systems.
Step 2: Integration recommendation
Information collection
Primary technical contact or business contact for the system receives a survey of about 15 questions specifically around the system’s integrations. Support for completion of the survey is available via open office hours with the ASP integrations team.
Next step
Integrations team member/s and a business analyst meet with system contacts and/or unit leadership to discuss the integration recommendation and considerations including:
-
- Types of integrations available to the system and the recommended type of integration
- Impacts to vended solutions and ability of vendor to respond
- People/skills available within the campus unit to update the integrations
- Cost considerations (licenses, external support if necessary)
- Timeline
Analysis & recommendation
The integrations team reviews the survey responses and follows up as necessary to arrive at a recommended approach for integration.
Options
System owners evaluate the benefits of the ancillary system against potential costs, effort, and time needed to update the integrations. Ultimately, the system owner and campus unit leadership decide whether to proceed with the integration recommendation or to retire the ancillary system and seek other options for completing the necessary work.
This is an accordion element with a series of buttons that open and close related content panels.
Integration principles for system stakeholders
| Integration pattern | Modality | Description | Rationale |
|---|---|---|---|
| Direct integration with Workday | Cloud Connect | Pre-delivered connectors to cloud services | Connectors are the preferred approach where direct integration with Workday is warranted. Direct integration creates a tight coupling, so this should be used only where required. Tight coupling is warranted when a connected system requires close knowledge of the internal operations of Workday (such as the need to manipulate data within Workday). |
| Direct integration with Workday | Enterprise Integration Builder | Custom reports, extracts and ELT | Batch integrations against ERP systems are warranted when there is a high degree of specific domain knowledge or data, and a tight coupling with domain data is justified. Examples of this include: state or federal reporting where the data provided requires precise interpretation, or where regulatory changes must be regularly assessed and implemented within the ERP. |
| Direct integration with Workday | Workday APIs | Access to Workday APIs and Reports as a Service (RaaS) | Direct access to Workday APIs creates a tight coupling, and in many cases will provide more data than is needed for the specific business purpose. This integration pattern is most suitable for building out functionality within the Workday platform itself (e.g. Workday Extend), or within systems that operate as sidecars alongside Workday. |
| Integration via Integration Hub | Integration Platform (IICS) | Integration with HR or Finance data via IICS | The Integration Platform provides a loosely coupled integration pattern that does not create a new direct dependency on the ERP platform. The interface can provide some normalization of data formats between different domains so that clients do not need to navigate radically different structures or modalities to consume data from multiple domains. |
| Integration via Integration Hub | APIs and Events | Integration with Person or other institutional APIs or events | Institutional APIs will rationalize data presentation across different business domains to allow for consistency and ease of use. Institutional APIs will also be integrated with institutional data approval and security review (RMF) processes to allow for unified data approval and inherited security controls. |
| Integration via Integration Hub | IAM / Provisioning Infrastructure | Integration with grouping, provisioning or login infrastructure | IAM systems calculate effective rights based on ‘additive privilege’ and, therefore, require aggregation of roles across a number of sources. Effective rights may also need to be adjusted or terminated based on factors in a number of different systems (HR/student role changes, security actions) so require an aggregated view of a person across different business and data domains. |
| N/A | Variable | System stakeholders are responsible for integration | In these situations, integrations are the responsibility of the system stakeholders:
|
Step 3: Security review
Information collection
Members of the Cybersecurity team will initiate an abbreviated risk assessment questionnaire and will meet with business contacts to collect and document the necessary information.
Next step
Security analysts work with system owners to create action plans.
Due to the number of systems involved and the complexity of the risk assessment, review, and action planning process, this step will likely continue beyond implementation of Workday on July 1, 2024.
Analysis and report
After analyzing the information collected, the security analyst will issue a risk review report with recommended actions to mitigate identified risks.
Options
Ultimately, the unit risk executive has responsibility for ensuring each identified risk is either addressed or acknowledged and accepted.