Sandbox Server

Minor updates to operating system and software on our web servers happen during regular maintenance and can be applied in place (generally with zero downtime). But large version changes have to be handled differently. We have several major upgrades to explore.

Upgrades

CentOS

Until this year UW had an education license for Redhat Enterprise Linux. This year UW decided we were getting little benefit from the license and will not continue the contract. CentOS is the free software version of Redhat, we have to move our web servers to CentOS distribution by July 2016. At that point we will no longer be able to get updates for Redhat.

CentOS 6.X to 7.X

The Redhat to CentOS move is actually a fairly easy transition that could be made in place. But our Redhat servers are a major version back and our newest web server is running CentOS 7.X. We want all of our servers on the same OS version.

PHP 7

A major new version of PHP has just been released. There are some backward compatibility concerns, but this new version comes with major performance improvements. This means our web sites will be faster and also cheaper to operate (PHP 7 uses significantly less memory). These would be great benefits, however we can't make this migration if our web applications are not compatible with the new language version.

MySQL to MariaDB

You can google "MySQL vs MariaDB" if you are curious about open source software complexity. For simplicity sake I will leave it at Redhat 6.X supports MySQL packages, CentOS 7.X supports MariaDB. Theoretically this is a 100% compatible change from our web application perspective.

PubCookie to Shibboleth

When you sign in to our web applications you do that with your UW NetID through the official UW Login Servers. There are two pieces of software that can communicate with the UW Login Server and let us know who you are. PubCookie is the older system that is no longer actively in development. PubCookie no longer works on CentOS 7.X (Apache 2.4). Now is the time for us to start using the new Shibboleth single sign on system.

Sandbox

With multiple major changes like this we want a safe, isolated place to see how our web applications will run and iron out the migration and deployement process.

For this we create a sandbox server, a testing location for the new software stack. Once we work out problems and have a vetted deployment process using our sandbox environment we can deploy the new stack on the live web servers.

Educ: Unified Application Infrastructure

The College of Education has somewhere between nine and a dozen (depends how you count them) distinct information system applications.

Building these applications separately had some advantages. It kept the domain logic specific, gave a clear context to design decisions, prevented cross system bugs, and let us keep iterating on and improving our framework. But it has gotten to the point where the technical debt of maintaining those multiple systems is impacting our ability to deliver new functionality.

Going forward our plan is to have a shared infrastructure that we implement new applications in and when the opportunity arises fold the existing applications into the shared framework. We are calling the new unified application infrastructure "Educ" since it will potentially house all College of Education information systems. The new Person and Budget databases are built in Educ and Appreview Plus project includes migrating SOARS to the shared framework.

Within the Educ project we create "contexts" so the single application and database under the hood can still appear as distinct systems on the surface. Switching "contexts" between Person and Budget and Appreview gives you different titles, menus, and search scopes. It looks like you are switching applications, but you are navigating between sections.

Educ uses Laravel which is a robust, popular, and high performance PHP framework. Educ has a shared person repository which allows greater consistency of data and easier sharing of information across contexts.

Appreview Plus

Our existing online applicant review system (SOARS) was built as a view on top of the live Graduate School application data. When you look at the detail page of an applicant in SOARS, a big chunk of what you see gets queried real time from MyGrad. This met the original specifications and has the nice advantage of being up-to-date and authoritative, but it has several downsides.

If Graduate Service goes down, SOARS goes down
The only applications we can have in SOARS are ones that come from the Graduate School
Once the Graduate School stops making applicant data available through the web service, it disappears completely in SOARS

To address these issues we have decided to build Appreview Plus. Appreview Plus will operate like SOARS feature for feature. But it will store application data locally and the application data will be structured for College of Education needs. For graduate applications the data will still map back to the Graduate School and get updated from their web service. But it will not be a requirement for there to be Graduate School data for our system to have data. This decoupling allows

Continue to view old application data (e.g. for current students) after MyGrad application is removed
Have local applications included side by side with MyGrad applications (e.g. existing students who change programs or continue on to additional degrees)
Able to handle applications from students that don’t apply through Graduate School (e.g. ECFS)

While we are restructuring data to exist as local application records we are also restructuring to better integrate the data with other systems. This offers many potential benefits, two big ones include

Inclusion of application data in student data views (e.g. Statement of Purpose, previous degrees, contingencies visible in STEP).
Shared storage of Person records simplifies administration and reporting.

This is a big project we want to do thoughtfully over the Summer (2015). This means reviewing existing system with SME’s and thoroughly reviewing existing code and database so we protect current capabilities while implanting the new features.

Ticket First

Our initial requirement for the Business Operations database (Bizops) was to implement an electronic version of the travel form. This was a complex process that frequently required back and forth revision so it was identified by the college process improvement group as a first place to focus.

The Bizops system was built using code from the Help Desk ticket system which contained many useful entities like Tickets (a project or task) a requestor, a person responsible for completing the work, a collection of messages related to the ticket, etc.

As we talked with the fiscal team we became concerned that Bizops: Travel Form might be another disjointed collection of tasks to keep track of. If some work is listed in email, some is in one-of-three excel sheets, some is in the shared drive, some is on a post-it, and now some are in the Bizops: Travel Form, it can be messy.

“Ticket First” represents our plan to surface the Ticket concepts and user interface from the existing Help Desk code so that Bizops can be a repository for any request, any task, not just Travel Forms.

Travel Forms now become an extra artifact related to the ticket. The ticket structure provides the context for who the requester is, who the staff responsible is, and what messages went back and forth about this particular travel form.

Ultimately it will be up to the fiscal team to decide if Bizops tickets helps them track work and share information.

Spring Quarterly Roadmap Feedback

Below is a summary of the feedback received from our first quarterly roadmap meeting. Those present at the meeting included members of the Academic Staff Team, Fiscal and HR, Grants team, Office of Student Services, Technology Office, Teacher Education, Associate Dean.

Feedback solicited included information about subject matter experts and considerations for development with respect to the following four Epics:

Reporting and Information Dashboards

SMEs: Office of Student Services, Research Unit, Financial Staff, FOG+, AD’s (including Teacher Education Dean).

Considerations:

Ability for reporting/dashboards to be utilized across platform
Using data visualization software, Tableau as a solution?
Any need for public dashboards? Dynamic reports on CoE website
Applications reports: ways to select what info. you would like to pull for a report (name, gpa, email, etc.)
Dashboards (current enrollment info, application info, financial aid, support sources of?, enrollment in classes)

Grants

SMEs: Grants team, director admin/finance, AST (for helping w/submitting reimbursements, etc.), Faculty

Considerations:

Who is assigned to oversee a particular budget (Roberta, Alayna, Juan, Eric)
Pre and Post award staff need to access info
Place for staff to access basic info (current grants: PIs, budget #)
All Budget # download (fiscal assignment)
Info includes all funding types
Multiple eGC1#’s and budget #’s for one “Grant”
Update grant data daily vs monthly
Weigh pros vs cons to see if it adds more layer of system management vs workload reduction grant management when a new system is introduced
s/b budget database: pre award? post award: fiscal/budget owner, salary encumbrances, BN, PI + delegated approval person

Accreditation Reporting Requirements

SMEs: admissions staff, certification program staff, certification faculty program heads (school psych, L4L Danforth), edTPA coordinator, certification officer, TEP Directors (requirements + progress), AST lead, Patrick (connects to Professional Division Dean + Directors), TEP Recruiter

Considerations:

Strand data whenever possible
Flexible architecture (in case of future changes/additions from PESB)
Include admissions file+rubric data
The ability to pull reports of multiple data points (eg admissions rubrics and edTPA)
Export features so we can run reports
How do test scores get entered into database? Do we need staff to key data?
Transfer all application documents to S-TEP “profile” for program access
Include option for signature assessments (numeric + text data)
Customize report templates

HR/Payroll

SMEs: HR director, payroll coordinator, FOG+, Research Unit, Financial Managers

Considerations:

Connect courses with hiring/budgeting
Salary D-base & Forecasting should be its own epic
Salary encumbrances, Fiscal / Budget owner, Salary transfers, distribution
- OSCTS
- Distribution changes
- Approval
Is there a need for supervisors/managers to have any of this info?

Requirements, Stories & Epics

Good requirements are critical to building quality software efficiently. Having shared strategies to define and document requirements helps users, subject matter experts, and developers build a shared understanding of what is needed.

Stories

User stories are a strategy for describing requirements for a small contained feature. By convention stories include a role, an action, and a reason.

As an AST I need the ability to see who changed a course plan record and when so I can resolve discrepancies correctly.

Ideally stories describe distinct deliverable functionality that can be translated to development projects which can be completed with a development cycle.

Epics

Stories will vary in size and scope. Big stories describe general needs and (hopefully) can be broken down into smaller addressable stories.

We refer to the top level stories as Epics. Epics may never be “done”, they can describe ongoing needs. Epics provide a way to describe overall organizational needs and give us a tool for prioritizing at high levels.

Prioritizing Epics and Stories and Work

We prioritize epics to develop a shared understanding of the goals and needs of the organization. We develop stories that describe contained achievable goals that support the epics. We map the stories to projects, units of work that can be achieved during a development cycle.

Those projects are prioritized on many factors including…

importance of the epic
importance of the story
real world dates, events, and deadlines
immediate value provided
risk reduction
ready to be worked on, dependencies are satisfied
size of project, easier to schedule small contained projects

Karen and Paul will draft these priorities and then seek feedback in our cycle planning meetings.

A great article describing “story” and “epic” terminology”

http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

Epics

Epics describe the top level goals and projects of the college for information system development. We’ve proposed a prioritized list of how urgent these epics are to the college, but we will seek feedback about this prioritization in face-to-face meetings including our quarterly roadmap planning meeting. This list and the priority order will continue to be refined.

Urgency level of epics is an important factor in prioritizing work for development cycles, but other factors including completeness of requirements, due dates, dependencies and organizational risk are considered.

Bullet points are example projects to help explain the epic, they are not a complete list of work to be done on a given epic.

1. Grants

College needs a shared location for grant information to clarify support staff and keep deadlines visible.

Fiscal support staff review
Due date reporting
Grants budget reporting

2. Meet Reporting Requirements

College needs to be able to respond to external reporting requirements to meet legal obligations, retain credentials, for program improvement, and to receive recognition.

Database for test scores from various sources tied to applicant and student data with verification workflow
Create tools for certification officer to comply with OSPI recommendation requirements
Teacher education online assessment forms
PESB data manual
Refine applications to support PESB requirements

3. HR/Payroll

College needs tools to support HR and payroll processes.

Way to capture large budget encumbrances (e.g. faculty salary)
Implement new hire forms and workflow as part of a request system

4. Reporting and Information Dashboards

College needs to have usable and understandable access to the data in our information systems.

Tableau dashboards for information system

5. Fiscal Business Operations

College needs tool for organized submission and tracking of fiscal business operations request to insure completeness and provide visibility of progress.

Implement fiscal forms in business operations ticket system (starting with travel and purchasing)
Link forms to other relevant systems

6. Better Use of Applicant Data

College needs to retain and fully utilize applicant data for advising, program evaluation and reporting. Currently much of our applicant data is provided by the Graduate School and after a time we lose access to it.

Eliminate outages due to back end downtime
Undergraduate applications and online review
Ability to evaluate selection process by program
Attach applicant data to student record to support advising

7. Authoritative Person Data

College needs shared authoritative resource for information about people. Person data should integrate official UW data wherever possible.

Support HR and Payroll work flows, easier onboarding and offboarding of employees
Reduce administration across information systems, better access management
Data more consistent and up-to-date across systems

8. Course Planning

College needs tools to expose a shared plan for curriculum and course scheduling. Courses need to be staffed and mapped to funding. Course scheduling needs to be timely and accurate.

Program curriculum grids represented in Courses Database
Faculty teaching expectations and load accurately represented

9. Program Management & Advising

College needs tools to administer and report on academic programs and individual students.

Track certification and endorsement programs
OSS online petitions

10. Infrastructure Improvements

College information system infrastructure must run smoothly and efficiently so less effort is required on maintenance more attention can be paid to new features and improvements.

Upgrade servers to PHP 5.5
Migrate applications to shared infrastructure
Create connections to UW central data to simplify data updates

Agile Development

We are currently adopting an Agile Development strategy for work on the College Information Systems. There are many definitions of Agile Development; below is our planned implementation of this methodology.

Two Week Cycles

We will plan and execute information system development work in two week cycles. Larger projects will be broken down into smaller deliverable chunks. At the end of each two week cycle College stakeholders can attend a regularly scheduled meeting to review progress on smaller project deliverables. This process allows us to refine our plan regularly and stay focused on producing the tools and data the college needs most.

Quarterly Roadmaps

We will prioritize development project work by generating Quarterly Roadmaps. These roadmaps will guide the Two Week Cycle planning as well as communicate project timing and rationale to College stakeholders. Input on quarterly roadmaps will be solicited from a variety of College stakeholders during the quarterly meeting as well as various individual contacts during the previous quarter.

The Roadmap will guide the Cycle planning and help us evaluate results. We realize new information and priorities can cause the Cycle planning to deviate from the roadmap and will use a quarterly planning cycle to incorporate the changing landscape while keeping development focused on the College’s priorities.

Subject Matter Experts

For each project we will identify college faculty or staff that are the domain experts for the systems we are developing. We will meet regularly with the experts during the two week cycle meetings to understand the business rules, to refine requirements, to prioritize, and to get feedback on work complete.

Regular Communication

A core agile principal is regular communication between the stakeholders and development team. As such we’ve outlined the following ways of communicating with stakeholders:

Quarterly roadmap planning meetings: We will be inviting all interested COE faculty and staff to quarterly meetings. At these meetings we will present our quarterly roadmap and ask for your help validating and refining our plan.

Bi-weekly cycle review and planning meetings: We will review work completed in the previous cycle and discussed the selected work for the next two-week cycle. This is another opportunity for interested COE faculty and staff to review and adjust development priorities.

IR Blog: While we highly value face-to-face communication we know it is not possible for everyone to attend all meetings. We will use this blog to announce plans and to provide reviews of work complete.