Data Delivery Strategy

Definition and Overview

Data Delivery refers to “getting the data out” of PeopleSoft, usually by means of reports or ad hoc queries, whether it is for operational reporting or trend analysis/decision support. This is a critical success factor for the STARS project.

Central to the Data Delivery strategy is the use of DD tools and applications against the RDS (Reporting Database Service). The RDS is a database separate from the PeopleSoft transactional system that is designed specifically to handle fast and easy ad hoc queries, extracts and reports, both operational and trend analysis/decision support. The RDS will contain information on all areas of PeopleSoft Student Administration (Admissions, Campus Community, Financial Aid, Student Records, Student Financials), for all careers (Undergraduate, Graduate and Professional).

Goals and Benefits

Goals

• Reporting will be flexible, based on nightly-loaded data, and accurate, with multiple options for accessing the data needed.
• There will be varying levels of appropriate access to the data; access to certain sensitive data elements will be based on approved data access policy roles.
• Use of the RDS for reporting will save on re-keying the same data in multiple systems and will improve data integrity.
• The RDS will become the primary source for university-wide Student data.
• The RDS will support historical and future-dated reporting to support go-live Business Processes.
• Reports will be delivered electronically (via a common delivery channel).
• The RDS will be used for operational reporting where appropriate in order to avoid performance degradation on the transactional system.
• Deliverables will be built with enough broad applicability to avoid the need for creating numerous specialized reports. Where possible, reports and models will be consolidated to provide this broad functionality.
• Deliverables will be built with enough flexibility to avoid needing modification or customization of reports at the unit level.

Benefits

• Data will be relevant, easy to access and in easy-to-use formats.
• Data models will allow for efficient querying and reporting.
• Functional Developers will have access to the RDS and will participate in Working Groups in order to become early adopters and subject matter experts in each of the PeopleSoft Student Administration RDS subject areas across all careers, participating in validation for accuracy and usability of subject area data models, and providing local support for his/her area.

Tools and Deliverables (Data Delivery Methodology)

Determining Scope

The Data Delivery Statement of Scope for go-live is broadly defined as those deliverables in direct support of core Business Processes as defined by the IDP (Interactive Design & Prototype) sessions for:

• all areas of PeopleSoft Student Administration (Admissions, Campus Community, Financial Aid, Student Records, Student Financials);
• all careers (Undergraduate, Graduate and Professional);
• meeting current core business functionality in the following priority order:
  
  
  1. currently provided by central transactional systems and data marts,
  2. currently available from other PeopleSoft transactional systems (e.g. HR, Payroll),
  3. currently stored in local/”shadow” systems,
  
  as can be accommodated to fit the project’s go-live dates.

All deliverables outside this scope should be documented in the IDP sessions to be incorporated in later implementation phases. Planning for these later phases is included in this project.

Through participation in the IDP’s, STARS Data Delivery will begin the process of refining the Statement of Scope down to a detailed level by understanding deliverables within context of Business Processes. Lists of delivered PSoft reports, current legacy reports and data elements contained in legacy data marts will be reviewed as part of the analysis in detailing the DD scope. STARS Data Delivery will actively partner with Subject Matter Experts (SME’s) and meet with campus Functional Developers (from all careers - Undergraduate, Graduate and Professional) to review, revise and validate scope as documented in the Data Delivery Inventory.

The Inventory will be maintained by STARS Data Delivery and will list all deliverables,, including RDS customizations, data models, reports and ad hoc query (BrioLites) applications. The approved1 inventory will be made available through the STARS website to communicate status and scope at an individual deliverable level.

Requirements

Standard specification templates will be used to document reporting requirements. Each reporting item in the DD inventory will have a corresponding requirements document. DD will work closely with SME’s to create, validate and approve each reporting specification document as part of each IDP process2. As each requirements document is approved, any changes will follow the STARS change control process.

For items in the DD inventory, requirements will be reviewed to determine the best source of data for the report – the operational system or the RDS. While the RDS contains the majority of the data that is in the operational system, it does not contain all operational data and, as delivered, it was designed to provide current operational data (not effective-dated), rather than provide warehouse-level reporting that allows historical or “trend” analysis. “Gaps” in the RDS require in-house customizations3 and therefore may undergo a review and approval process with Project Director(s) and or Sponsor(s) for transformations that cause significant negative impact to the project schedule. The process for determining the source of a report and whether a customization will be made to the RDS is described by the Data Delivery Decision Tree (see diagram below).

DD Deliverables

DD has 3 primary delivery mechanisms (“tools”) – Brio Data Models, BrioLite Dashboards and Brio Reports. The determination of which delivery mechanism will be used will be driven by each inventory item’s requirements.

• Brio Data Models – a fixed, graphical representation of a predefined group of RDS tables used only by Function Developers for generating ad hoc queries and reports.
• BrioLite Dashboards – limited ad hoc application which provides formatted reports and defined results sets while allowing the end-users to perform some data manipulation without needing the level of expertise required by Functional Developers. We expect this to be the most commonly used Data Delivery data access mechanism.
• Brio Reports – meets highly specialized reporting requirements, usually due to the need to secure the document to a limited population; lacks the features to meet a broad set of business needs.

Back

Build Deliverables

Data Models form the foundation for all DD deliverables, i.e. all deliverables contain or are contained within a Data Model. Where possible, the strategy is to use the RDS as close to its delivered form as is appropriate. As delivered, the RDS contains “generic” models that are meant to be used as baselines to be tailored to meet each individual Higher Ed institution’s reporting needs. Models will be built to support business processes across functional areas as defined by the IDP’s and from input from Functional Developers. Some of these multi-dimensional processes will require DD to create new Data Models using an approach called Dimensional Modeling, which tends to move the models to the database, causing fewer changes downstream to be made at the reporting tool level. Dimensional Modeling will allow us greater flexibility to extend existing models to incorporate data needed across functional areas in future phases of the phased implementation. Dimensional Models will be built from tables that consist of data extracted from PeopleSoft transactional tables, transformed into more reporting-friendly formats and loaded into the RDS on a nightly basis via a vendor product called DecisionStream.

Testing

See STARS Testing Plan documents for Data Delivery Testing details.

Training

See STARS Training Strategy document for Data Delivery Training strategy.

Assumptions and Risks

Assumptions

• DD is not responsible for PS transactional reports and/or other non-RDS reports.
• Reliance on Legacy and local systems for reporting will diminish over time.
• Deliverables will be built with enough flexibility to avoid the need for modification or customization of reports at the unit level.
• BrioLite Dashboards will be the most commonly used Data Delivery data access mechanism.
• Currently, the Student Records Data Mart supplies bio/demo data on students for the Financial Aid and Bursar data marts. Once shared tables, such as the legacy Data Mart “student” table, are replaced by the RDS, we need to determine how to supply the dependant legacy Data Marts with the back-fed appropriate data.
• Functional Analysts will be available for all phases of the project as needed (see Roles & Responsibilities).
• The majority of the phases and their respective IDP processes will be identified prior to any deliverables being moved to production.
• The phased implementation will plan for adequate stabilization periods.

Risks

• Inadequate testing of models, BrioLites, or reports may result in numerous risks, such as inconsistent or incorrect data, end users’ inability to properly perform business functions, etc.
• Inadequate or delayed DD business analysis may result in missing deliverables for go-live.
• Insufficient access to/participation from functional experts (SME’s) may result in missing or incomplete deliverables for go-live.
• Limited understanding of the PSoft system’s operational data could lead to the development of erroneous deliverables.
• A phased implementation will likely affect our ability to support remaining legacy Data Marts. Additional resources and rework may be required.
• A phased implementation may result in incomplete reports, i.e. reports may not have all the data elements needed until further along into the project.
• A phased implementation may require continual revisions to data models that may already have been moved to production in prior phases, resulting in a greater impact on the end-users and user-support.
• Higher levels of resources for stabilization, which will be concurrent with additional phases’ development, may be necessary for a successful phased implementation.
• 8.9 upgrade timeline has a negative impact on the project.

Roles and Responsibilities

The Technical Analysts and Developers of the STARS Data Delivery team will be primarily responsible for the analysis, design, development and unit testing of standardized dimensional Data Models, BrioLite Applications and Reports needed for go-live. In addition, the DD team will be responsible for/participate in the following:

• Providing business analysis for IDP's
• Maintaining the inventory of RDS customizations, reports, BrioLites and data models
• Maintaining the requirements templates for reports, BrioLites and data models

The Data Delivery team will work closely with Functional Analysts (Subject Matter Experts) from the STARS team to gather and document requirements, test scenarios and acceptance criteria for DD deliverables. This team will work closely with other STARS "sub-teams" as follows:

• Campus Readiness - develop training materials for use by end users, Functional Trainers, Functional Support Providers
• Testing – develop test scripts based on test scenarios and acceptance criteria for user testing of BrioLites and Reports

The Data Delivery team will also be responsible for communicating changes originating from DD analysis. That is to say if DD analysis uncovers the need for a different Gap solution other than DD (e.g. report needs to come from the transactional system vs the RDS), DD will initiate the necessary communication to all affected STARS “sub-teams”. The DD Inventory will serve as an important tracking & communication tool that can be referenced by other sub-teams such as Testing to determine deliverable status.

The STARS Data Delivery team will work closely with CIT Technical Analysts, Developers and Support Providers from the CR and HR Data Delivery areas, as well as with the Functional Developers in Working Groups across campus as follows:

CIT:

• Following standard dimensional modeling techniques
• Using/developing standardized templates
• Defining common methodologies
• Cross Training

Functional Developers :

• Representing DD needs from colleges and units across all careers - Undergraduate, Graduate and Professional
• Exercising existing in-depth knowledge of Student data as well as in using the Brio Explorer tool which accesses that data
• Actively participating in Data Delivery development as part of a defined DD Working Group
• Reviewing, revising and validating scope as documented in the Data Delivery Inventory
• Defining requirements /performing user testing of Data Models for ad-hoc query and data repackaging needs

Back

1 DD Inventory Prioritization process

• Needed due to regulations?
• Needed to support university policy?
• 80/20 – go-live deliverables will be targeted to meet the needs of the broadest audience possible… high ROI

DD Inventory Approval process for items meeting Prioritization steps will be negotiated between the Project Director(s), Project Management, DD and the Module Lead(s). The Inventory Approval process will determine which inventory items are in scope for go-live and which deliverables are deferred to a successive project phase.

2 Module Lead will sign reporting specifications approvals, guided by the validation from the SME.

3 RDS Customizations differ from modifications to the PSoft transactional system in that they are not handled in the same way during an upgrade.

Back