Integrating the Student Information System and Blackboard - you just press a button, right? - Alice Fage, Andrew Matthews and Marcus Uy, Victoria University of Wellington ANZTLC15

Editor's Notes

1. ANDREW Introduce yourself, Marcus and Alice. Describe what the presentation will cover + and at the end time for questions, or for people to share their expertise and experience.
2. Describe Victoria University of Wellington – location, campuses, size (EFTS, staff), faculties, schools, CSUs.
3. Describe Victoria University of Wellington – location, campuses, size (EFTS, staff), faculties, schools, CSUs. Eleanor Catton – 2013 Man Booker prize winner
4. In 2014, Victoria University began a project to replace the existing data integration system between the Student Information System (Ellucian Banner) and Blackboard Learn. What is meant by integration – what this covers – automated provisioning of student accounts, courses, student enrolment in courses, staff assignment to courses, from Banner to Blackboard. So - multiple systems involved: LMS – Blackboard, SIS – Banner, IdM – multiple And – multiple business owners – CAD [say who they are], SAS [say who they are], ITS [say who they are]
5. Many stakeholders and end users – CAD, SAS, ITS, lecturers, school admins, students. Some functions centralised, some not. Different “cultures” around the two main systems involved.
6. Current system developed 10 years ago using Crystal Reports (which is not widely used in the University) and Blackboard Command Line Snapshot. Worked pretty well, but needed replacement as hard to maintain and set up each year, took a lot of effort to move e.g. on to new software versions. Also changes in the Student Information System meant that some parts were not working e.g. when students dropped courses, they remained in the Blackboard course until a manual batch job was run which was time consuming to do. Move to Managed Hosting meant that existing system would not work as it depended on directly accessing the Blackboard database (to create the delta difference files for the Command Line Snapshot feed files). Blackboard’s Command Line snapshot tool was deprecated and might disappear at a time not of our choosing. Also keen to take advance of some new features of Blackboard (Terms, parent/child courses_ and add enhancements such as automatic assignment of staff to courses based on Banner data (currently done manually). Reduce administrative overhead (Service Desk, school admins, lecturers – examples) To drive improvements in Business Processes around consistency of practice and reinforcing the importance of the SIS system being the source of truth for Student/Course and Instructor information.
7. Phase 1 Part 1, Phase 1 Part 2, Phase 2 Requirements gathering was done by holding stakeholder workshops, particularly with end-users. (show example of requirements document) RFP process. Chose to go with Blackboard’s SIS Mentoring service and in-house development. Not an easy decision as there was a desire to use off the shelf solutions and there was a real fear that by building part of the solution in-house, we would be depart from the Baseline Strategy. Project team: (list team members) Ange, Sam, Alice, Twingle, Venky, Toni, Brian AND Blackboard – Marcus Uy
8. A lot of folk misunderstand that the SIS mentoring service to be about technical support and guidance through the integration process. There is a very critical portion of the service that is technically oriented, but a far larger part of the effort has to do with getting all the stake holders to sit down and engage one another to create the underlying business process. It’s these processes that are then translated into the relatively simplified “language” of the SIS framework provided by Blackboard Learn, alongside a host of other features to implement the desired behaviour of the SIS integration.
9. We typically arrange the service delivery along the lines of more technical workshops to define and share the basic nuts-and-bolts operation of the SIS framework as well as synchronize the lingo to describe the moving parts. That gradually transitions to consultative sessions with stake holders to build up a business process document we call the Data Planning Workbook. Which itself transitions to discussion about best practice and testing edge cases.
10. Let me be the first to say that the project conducted by the VuW team was among the most exemplary I’ve seen in some time. Typically there’s a certain amount of feet dragging when it comes to putting together the workbook. There’s lots of reasons for this. Technical topics often fall under the locus of control of just a small handful of the project team – it’s very easy for the technical folks to progress and test an SIS design. Getting together a group of people from cross-functional areas tends to be a lot of work, and it’s time consuming to achieve consensus – so it’s natural to find aversion to the process. But it is a necessary process. My observation as a bystander to a lot of the work was that many broad areas, the typical 80% of the project, could find relatively easy agreement and went into the workbook without much trouble. The remaining 20% was where digging, discussions, agreement, change and more agreement with admissions, academics, staff and others required more time, and often presented the edge cases the required thought and testing throughout the engagement.
11. ALICE As Andrew has outlined, we started with requirements gathering for the RFP process. This was done by Ange (project manager) and Sam (Business Analyst). Workshops – who attended. We also identified the technical/vendor options available to us. My role: advising on the current processes and use of Blackboard, Blackboard functionality, and overseeing the Blackboard configuration side.
12. Blackboard SIS Integration Mentoring service was chosen: Our perspective of the SIS mentoring service: We had actually covered a lot of ground covered in the workbook when gathering the requirements for the RFP – but Sam went through the document – which was a LOT of work – it’s a long document. When new questions arose more workshops were held. The sessions with Marcus were very useful for discussing the areas we needed to pay attention to, and the more tricky technical (e.g. choosing a data source key strategy). And then in practice, when implementing – we did need some technical assistance. Bb’s Snapshot flat file documentation could be improved. Some areas are confusing – for example, different names are used for the same fields in different parts of the integration. Lots of trial and error. (Make sure you have test environments set up with good quality representative test. This was quite time consuming to achieve but very, very important.)
13. Never make assumptions. (You may not realise they are assumptions). We had it in mind that Banner had strict business rules and that the data was accurate. This was not always the case. Turns out the data in Banner is not always accurate and functions can be used in quite different ways by different schools. E.g. cross-listing, or joint/multiple labelled courses - one course had 10 CRNs (offerings, or instances of a course). 9 of these were cross-listed with each other. Over 4 trimester codes. Over the course of the project I sent a lot of emails to the Course Administration team, who then had to talk to the schools to find out what was going on. A good thing was that a lot of things got tidied up, but there were still instances where cross-listing was used by schools to mean different things and we just have to live with that. Another example - Joint courses – also called multiple labelled courses. E.g. But only one half is offered. The second label has not been offered for 5 years. Why do people hold on to these? There is an incentive (difficult to get new courses, easier to swap out existing one). Oddities in Blackboard use – enrolling unenrolled students. Trimester changes, new course offerings, changes in course structure after the courses have started – for perfectly legitimate reasons. [ELIN example] In the middle of this project, we also moved to Managed Hosting. This meant resources were stretched and environments were changing.
14. Another big challenge was that stakeholders had different views, so we had conflicting requirements. (Include that we received quite a bit of “feedback” about Blackboard itself that we had to field / raise enhancement requests about.) [go through some of them]   Who can make these decisions when you have multiple business owners and stakeholders involved?
15. Technical Architecture team did not want to expose Banner directly to the Blackboard Managed Hosting environment network. This meant that we needed to build an extra integration layer on separate hardware. Resources were not available for this in the integration project, so we managed to attach them to the Managed Hosting project instead. Choosing a model for loading the data – frequent deltas or bulk load? Tied closely to other decisions such as how often it will be run. Chosen a daily load to simplify the code side and easily handle students dropping courses. Timing: When to implement? Academic calendar. Always going to be some overlaps as you are always preparing for the next trimester’s courses . Or, nearly always… Point at which the old integration was not going to work with the old courses so we were committed to the project even though it was still in the early stages of development. Scope creep – new requests coming in that weren’t necessarily directly related to the data integration project, e.g. including course outline content in Blackboard courses. There was a very real danger that this could derail the core work planned. This was dealt with by adding new phases so we had Phase 1 Part 1 (core functionality), Phase 1 Part 2 (extra time-critical scope to be dealt with only after Phase 1 Part 1 was complete and Phase 2 (other enhancements). Fortunately we could be firm about this as the impact of not getting the core work done would be severe.
16. How we ended up making these decisions: Case-by-case basis. Often chose to go with the status quo e.g. email addresses. Had to look hard at the BENEFIT and the COST. At the end of the day, CAD had the final say in what went into Blackboard, as they are the business owners of that system. However, we could not make any changes to the way things are done in Banner without SAS approval. E.g. staff assignment to courses – had to be a driver for that, and fortunately there was in the form of another project, so we could piggy back on to that. Future-proofing. Informed in part by the workshops, and in part by trying to anticipate implications of decisions made, or mitigating changes. While we generally prefer not including data in feed files that doesn’t need to be there, we do in this case bring through some extra fields so that we can use them in the future if we need to. E.g. multiple email addresses, first name, preferred name, middle name. How it would be advertised to end users – this was considered with every decision.
17. Current state of the project Phase 1 part 1 completed last week (full automation of students, courses, student enrolments).
18. ANDREW As Alice said, have retired the old system and are now with Managed Hosting, so that counts as a success.
19. What worked less well? Lengthy RFP process meant shortened time to implement – very tight timeframe – January to July. Project resources were not allocated 100% to this project but to others as well, and Business as Usual activities.
20. What worked well? Workshops and requirements gathering were essential and really the difference in why the project succeeded and why the previous attempt did not. We now have a good group of stakeholders and understanding of the Banner and Blackboard processes, and have started the process of reforming some of our Blackboard processes and hopefully reducing some administrative overheads (e.g. merged and split courses automatically flow through from Banner). Strategy Basic principle – can boil things down to “does this support our University’s strategies”? This can be quite a useful lens to view things through to give a different perspective. E.g. “Does this enhance the student experience? Yes? No?”? or “Does this support the Learning and Teaching Strategy or does it add administrative overhead for lecturers?”
21. [Overcame organisational issues] More a case of careful negotiation. This is going to be a lengthy work in progress and challenging – maybe impossible. Would say we uncovered more organisational issues than we overcame – remains to be seen fully how this impacts on the new integration system as we implemented halfway through the year. A shift in the way people will have to do things – e.g. if they want it in Blackboard, most of the time it will have to be in Banner first. But there are wider issues in terms of the variation in how schools use the systems, and the different timelines that are involved. Interdependencies within systems and projects Systems are becoming less isolated not just technically but in terms of how they used (e.g. analytics, student retention systems). So projects covering multiple business owners and units will become more common. Important to learn from each project and take it through to the next, and build that network of relationships through the institution. Where next / lessons learned in terms of the organisation aspect? Take away for engaging with multiple stakeholders and business owners. [Aside from “always provide biscuits”]. We did not have a direct student voice on our panel of stakeholders, although we did have Student Services representation. It would be good to get the students’ view of our processes, although this would be a wider undertaking and outside the scope of this project.
22. Future enhancements: System may be replaced altogether (Ellucian products). Want to look at grade exchange (with approval process) from Banner to Blackboard.
23. MARCUS Brief overview of grades journey. [Mention Michael Garner’s Grades Journey session – Thursday 3.15pm in Hickinbotham Hall just before the closing session.]