Administrative Systems Modernization Program ASMP 2.0 Technical Update April 2, 2014

Agenda Program Update – Renee Wallace Distributed Systems Update – Dana Cook Technical Architecture Overview – Julienne VanDerZiel Technical Architecture Design & Specifications - Eric Weigel & Cooper Henson Technical Architecture Next Steps – Julienne VanDerZiel

ASMP- Case for Change Desire to take advantage of technological advancements Mitigate risks of relying on aging technology toolset (Adabas/Natural are reaching end of life) Integration with third party open standard systems is very difficult and expensive in the current environment Up-to-date standards and best practices are difficult with current toolset Difficulty attracting and retaining workforce

Administrative Systems Master Plan ASMP 2012 2014 Create Business Driven Systems and Data Management Modernize the Administrative IT Infrastructure Strengthen the Systems Development Processes Implement Workday for HR/Payroll and Finance. Student-TBD. Transition distributed systems off mainframe. Develop Strategic Reporting Master Plan and Enhance IQ Implement Open Systems Technical Architecture (Integration and Development) Develop, Test and Deploy Standards and Methodology Processes Administrative Systems Master Plan Administrative Systems Modernization Program Illustrate how ASMP 2.0 is addressing the requirements stated in ASMP

Guiding Principles Open and transparent communication Involvement of key stakeholders Strong governance Adoption of best practice business processes Customization used only where needed for operational or competitive advantage Opportunities for career development

Current Activities Integration Partner Contract Negotiations Preliminary Planning Governance Staffing

Distributed Software Systems Planning Objectives Inventory of all Administrative Systems on campus Develop a master road map for all administrative systems on the mainframe by compiling road maps from all units and reconciling dependencies, resource needs, etc.. Note: Student Administration mainframe-based non-ERP systems planning and road mapping will take place on a separate timeline. More details to come.

Distributed Software Systems Planning – Status Update Inventory of all Administrative Systems on campus 100% participation; Completed! Some interesting stats… 1,569 administrative systems; 1,024 run or use mainframe resources 450 student systems; 399 shadow and supplemental 205 financial systems; 74 shadow and supplemental 137 HR/Payroll systems; 55 shadow and supplemental Develop a master road map for all administrative systems on the mainframe by compiling road maps from all units and reconciling dependencies, resource needs, etc.. Received 85-90% unit-level road maps; expect to receive the remaining 7 and have a draft master road map by the end of April

Distributed Software Systems Implementation Objectives Overall coordination of the modernization transitions throughout the ASMP 2.0 Program (sans ERP components) Provide transition support to units across campus (i.e. tools, best practices, help resolving issues, design, etc.) Facilitate cross-unit collaboration on common needs Assist in transition of interfaces to Master Data Repository as historical and cross-area data needs dictate

Distributed Software Systems Implementation – Status Update Staffing the lead and team for this area Defining initial list of transition support offerings for campus Best practice documentation starting (i.e. vendor product selection, suggested contract language, etc.) Beginning to work with areas who are transitioning early (i.e. Development) Starting to pull together work groups around common needs and/or identifying units who can participate in efforts that are starting (i.e. Faculty Recruiting, Room Scheduling)

Distributed Software Systems Next Steps If you are still working on your road maps, keep up the planning and send to me as soon as possible. Do you have some ideas for how we can support you in the transition of your systems? Send me your ideas. Do you think you have some best practice documentation to share? Send to me and we can add to the collection.

Technical Architecture Scope: Support cloud, package and custom applications for Administrative units and their interfaces. Production Architecture: Workflow, ESB, Document Management, SOA Architecture, Database, Security and Authorization, Batch, Infrastructure, Monitoring Used by Workday ERP, Application Modernization, and community at large Development Architecture: Support standard framework, tools, and environment for application development, configuration, integration, testing, training and staging environments Configuration Management, tenant and integration environment management, development and testing tools Application Development standards and guidelines

Technical Architecture Status In negotiations to define Planning Stage Project High Level Diagrams and Requirements Completed from prior ASMP workgroups Goals: Architecture defined: end of Summer/early Fall, 2014 Design and Build: Fall, 2014 Development environments available: end of year, 2014 May build out iteratively to have some components available earlier Vision Meet the core needs of the administrative community, now and in the future Scalable, proven and flexible solutions to meet changing business and IT needs Standard, sustainable, and secure Promote reuse, increase speed and accuracy

Tech Arch Recommendations Open systems Open standards, interoperability Open source or propriety Key is to meet our business needs, not focus on the vendor of choice

Technical Architecture Overview Infrastructure – firm requirements Chipset: x86-64 bit systems OS: Linux Storage: High performance compatible w/x86-64 bit systems Virtual servers, ability to scale Databases: MySQL, Oracle, MS SQL Server Performance, secure, reliable, high availability

Tech Arch Recommendations Development Architecture - need to solidify Use Cases: Java is required for complex Workday integrations Supports PyPE, leverage enterprise investment Possibly other languages MF integration, Workday Cloud Connect Use during transition period and to close gaps in vendor ERP solutions Support packaged solutions Change Management (Software) Issue Tracking: JIRA enterprise instance Collaboration: Confluence Testing: Selenium Source Code Version Control: Subversion in place now, Git being tested Continuous Integration: Bamboo, Jenkins in limited use

Technical Architecture UT 101 for the Integrator

Technical Architecture Overview Workday Tenants Tenant Tenant Types Mapping Workday Tenants to UT Environments

Technical Architecture Workday Tenant Mapping Example

Technical Architecture Workday Tenant Mapping Example

Technical Architecture Workday Tenant Mapping Example

Tech Arch Recommendations Integration Architecture SOA Approach: loosely coupled, less expensive and easier to maintain Promotes re-use of services ESB: Implements communication between applications using web-services Increased flexibility Replaces point-to-point integrations BPEL and BPM: Standardizes business processes and workflow using SOA web services Abstracts business rules from coded solutions Promotes re-use of processes and workflows SOA: Service Oriented Architecture ESB: Enterprise Service Bus BPEL: Business Process Execution Language BPM: Business Process Management

Tech Arch Recommendations What does this mean to the IT community? Opportunities to learn new ways to develop applications using web services Application developer training is critical to success and will be provided Guidelines and standards will be developed, and SOA governance implemented Reducing point-to-point integrations will increase flexibility Re-use of web services will speed development

Tech Arch Next Steps Timeline Campus engagement Architecture defined: end of Summer/early Fall, 2014 Design and Build: Fall, 2014 Development environments available: end of year, 2014 May build out iteratively to have some components available earlier Campus engagement Campus Steering Committee forming now Vendor Technology Days Future FYIs - Workday Integration Series

Questions