Implementing KFS Release 2 (Let’s Get Cookin’!) Susan Moore / Jonathon Keller, UC - Davis Vince Schimizzi / Mike Criswell, MSU

Topics Mission Approaches Technical environment Distribution: What do you get ? Goals How did it go? Next steps Final thoughts (open discussion)

Mission (UC – Davis) Stay ahead of a production implementation in identifying issues. Review and provide input to installation and configuration documentation. How to structure deployment of application. Review new implementation functionality of KFS release 2.

Mission (MSU) Review, learn, and provide input on installation and configuration documentation. Begin to identify and review MSU configuration issues and to conduct modeling scenarios. Review new functionality in KFS release 2.

Approach (MSU) For bootstrap version (like a go-live installation) much attention was given to data, setup and configuration. Prior to release, functional/technical staff reviewed process from KFS release 1 and developed plan for KFS release 2. Upon receiving pre-release software, up and running in 3 business days. 3 technical staff, 7 functional staff.

Approach (UC-Davis) Wanted a “fresh” perspective. 1 technical staff part-time. 2 functional staff part-time.

Technical Environment UC - Davis MSU Hardware Application Server: Dell PowerEdge 1850 / Xeon 3.0 GHz 4 GB RAM / 73 GB HDD Windows Server 2003 SP2 Database Server: (not dedicated) Sun Fire V240 / 2 x 1.5 GHz CPU 12 GB RAM / 2 x 73 GB Internal HDD 550 GB storage on SAN Application Server: Dell PowerEdge 2950 with 2 Gig RAM, (2) 60 GB Drives, Fedora Linux version 6 Database Server: Dell Dual Processor, 8 GIG RAM, Red Hat Enterprise 4 - Linux (64 bit OS), SAN-based storage Database Oracle 10g for Solaris Oracle 10g for Linux (64 bit edition) Download Distribution Source Code Distribution Dataset KULDEMO KULBOOTSTRAP + MSU Data

Distribution: What do you get? Kuali Financial System Demo Data Set Bootstrap Data Set Database Import/Export Tool Kuali Rice Kuali Enterprise Workflow Sample Patch for Extended Attributes

Goals (MSU) Load MSU sample data. Implement an extended attribute. Create a custom business rule. Replace CAS Authentication with MSU’s home-grown authentication. Build the application from source. Test application.

MSU Load Process

Goals (UC - Davis) Build the application from source. Test application.

How did it go? (UC - Davis) Installation Functional testing

How did it go? (MSU) Installation went well (some expected challenges) Functional testing of transaction and maintenance eDocs went smoothly. Experience from prior load (table load sequence) was helpful in identifying new tables and fields. Referential integrity constraints helped ensure proper data load. MSU created Entity Relationship (ER) diagrams on application which was useful in understanding the underlying data.

Next Steps (MSU) Install actual Kuali release 2 application. Continue testing application once up and running Maintenance Edoc Transaction Edoc Batch processes Workflow capabilities Etc. Create supplemental implementation documents for MSU.

Next Steps (UCD) Load institutional data. Create additional business objects and extended attributes on existing objects. Replace CAS authentication with UC authentication.

Final Thoughts Overall smooth process. The lack of any substantive “show stoppers” is itself a sign of success.

Questions ?