 Welcome to another episode of Domains 21, The Track. I'm here by a very kind of cool, unique group that I saw percent just last month at the University API conference that's hosted and held by BYU. And I'll let everybody introduce themselves, but I was intrigued by the notion of this team and the work you're doing, obviously, and the team goes by the name of the Digital Transformation Team. And I was hoping you all could talk a little bit about that. So welcome to Domains 21, and thanks for coming. Glad to be here. Did you want to do introductions first, I guess? I'm JD Mills. I manage Davidson College's Digital Transformation Team. And we're just a very small project team that is kind of free from most operational responsibility so that we can focus on strategic technology initiatives that the college has designated as important. So among some of the things we've worked on recently are things like low code, a Davidson API potentially, ways that students and employees communicate with each other and all kinds of interesting things. So I will pass the mic to Tessa. Yeah, I'm Tessa Jones. I'm a Davidson College alum wandered into Charlotte and worked there briefly and then came back to Davidson. So I'm a Digital Transformation Analyst, part of the DX team. And like Armado says, we do a little bit of everything. I'm Luke Ashleman. I've been on the DX team as their second analyst for a little over a year and a half now. My background is primarily full stack web development. So I'm typically the, tend to be the programmer of the group but we all, like everyone has said, we all do a little bit of everything. So that's the team. Great, well, welcome all. I guess I did wanna talk a little bit about like a Digital Transformation Team, as you all said, seems like a novel concept. Like what was Davidson College thinking about and why is your team like in existence? What particular issues and problems around campus are you trying to solve, if that makes sense? So the story starts a little bit with the history behind the team and it's sort of ancestor team that existed prior to the Digital Transformation Team being founded. We had something called a Digital Innovation Team, which was, I guess, if you think about IT in the bimodal sense where you have the keep the lights on mode and then you have the innovate and try new things and fail a lot mode, it was in the latter. And it worked okay for a while. We had a very small team of myself as the Digital Innovation Systems Administrator or Systems Engineer and we had a fellow position and we also had a full stack web developer position. But because we were focused on basically pure exploration and trying new things and trying to innovate, which was good for the org at the time, because we needed some new blood, we needed some new ideas, the longer that went on, the less connected to college strategy we felt we actually were. We found that our colleagues didn't really understand the value of having a team that worked largely on experimental stuff, developing custom software. And it just, you know, we had a leadership retreat at some point and decided we need to figure out what the future of this team is going to be. And the Digital Transformation Team is kind of what was born out of that conversation. We realized we needed to take, you know, some of this innovation skill set, but make sure that the work that we were doing was always connected to the college's strategic priorities. And so in setting up the team, you know, we kind of wrote this charter and wrote a mission statement and basically committed ourselves to being a small group of IT generalists who would be free from operational responsibility that could work on strategic projects and, you know, using our general skill set and our lack of operational load alleviate stress elsewhere in the org, whether that's optimizing some process that's used only internal to IT, whether that's joining a project that another group was managing just as a way to like infuse some extra labor into it or push an initiative over the edge that was otherwise teetering on the brink. And so, yeah, that's kind of how we got started. And over time, over the lifespan of the team, we found there's not only the technical angle and like the extra boost of labor angle, we've also developed this kind of business analyst skill set that because we come from a bunch of different backgrounds, because several of us are Davidson alumni and because we all sort of are of a certain mindset, we spend probably just as much time analyzing process and revising business process as we do implementing new technology. So what does that look like? It looks like, you know, collecting user stories about what a given set of requirements might be. It looks like, you know, any number of things basically around the analysis of a given solution and what we need to change to make technology a component of making that future state successful. It's interesting, because one of the things you brought up earlier, and feel free, Luke and Tessa to jump in at any time, but you mentioned earlier this idea of low code and then you pointed to the idea of, you know, generalists and working. I love the idea, frankly, of you all working, not as this esoteric innovation group somewhere out there doing something that has no concrete relation to the daily work. That's really a nice kind of frame, but also the idea that you're generalist, but yet you're thinking about specific user stories and how you can rethink some of the kind of relationships between business and how it gets done and how to make that more automated and efficient. So I'd love to hear more about your approach on the ground in terms of low code and what that looks like. Sure, Tessa or Luke, do you wanna take this story? Yeah, I think in terms of related to low code, you know, your traditional IT dev shop, and I've worked in higher ed for going on eight years now, you know, you have a group of application developers, and as with any development shop, you start to get a lot of technical debt, you start to get bit rot, and there's just the maintenance load prevents you from innovating. And not only is Davidson a lot, not only is Davidson much smaller, so they can't have this giant development team, but it also, because of Davidson size, we also wanna use the people who know how to code maybe just a little bit that can understand programmatic processes. We wanna be able to empower them and give them agency to maintain their own applications. So, you know, Davidson has a set of campus IT partners who are, you know, the major technologists stationed in various departments like the registrar or HR. And so our approach to low code is to make sure that we find tools that they can use and they can understand without requiring them to say become, to learn, you know, PHP or Ruby or JavaScript. Which typically involves, you know, some sort of GUI interface. It involves getting them integrations to our source systems so that they can use Davidson data, so to our HR systems and our student data systems. And then it involves training them and then supporting them with their needs. So if the low code solution doesn't support what they wanna do, we might get involved again and figure out, well, what are you trying to accomplish? What's the best solution to move forward? So again, this all stems from the idea that instead of hiring 20 developers to just custom code everything, we wanna find a generalist product and train our users on how to use it really well. It's interesting, and I don't think it's by mistake that when I met JD and Tessa, I think, for the first time, it was at the university API conference where you were going there to kind of, I think, figure out some ways to actually do what you're talking about, Luke, on the ground at Davidson. And I'd love to hear just like some of what you learned in your journey towards figuring out, A, what tools make it easy for your users to do it and maybe some stories around how basically you're introducing, you know, an API-driven approach to various universities. And I think I wanna be clear, like maybe we should define how you are thinking and imagining API. Maybe it is about forms. Maybe that's a better way to say it. But it is about, you know, comfortably giving people places to kind of deliver data in a clean way that can be used across the institution. So I know that's not really, it's more of a comment than a question there. I don't know what that is. So I'm sorry to leave you with that spaghetti and then jump out. But here I go. Good luck. Thanks, thanks. So I guess at the time that we were taking on the low code project, we had this, you know, these legacy web forms that we were trying to get rid of this technical debt that Luke is alluding to. And, you know, we ended up going the route that we did for several reasons. But again, we wanted to be an easy product. We knew that at Davidson, after having done that user research, that it had to be that type of solution. It couldn't be the type of solution that was so complicated that we, the IT department would be stuck with the maintenance and development of every single future product that a user might request for their departmental use. So that started us on the journey to find QualiBuild. And where APIs fit into the picture is, I think we've known since we started looking at low code solutions that we wanted to tie in institutional data through APIs. And we've had an integration platform available to us in the form of SnapLogic for some time that has helped us do that. But in the low code world, what that looks like to our users is, you know, us the admins configuring an integration that pulls from the integration platform or pulls from an API that we've written and presents it as a simple gadget that they can drop in to look up data or to send form data to another system. What else, what am I missing, Tessa, on the, on that story? I mean, I think we, yeah, we started low code really wanting to make so much of like what we do as accessible as possible to our kind of average users. And we spent a lot of time talking about like citizen development and student programmers. And I think that that was a group that on one hand was kind of hard to untangle like what they needed at first, but we kind of kept circling back to being a valuable case study. And that's where like really focusing in on the user stories that we had for our low code transition I think helped us make sure that our first step, which kind of had some clear goals wrapped into it into low code was very like user friendly. And we're just seeing that expand like because we started with that position of being very, very accessible to as many of our on-campus users as possible, we've seen them really like pick up that ball and run with it. So now we have a need to have even more kind of resources and features that allow them to keep moving forward with those low code options we've given them. It's interesting. So one of the things I'm hearing is, you know, you all had to do the groundwork to like go out, meet with people, say, here's what we're providing you, here are the tools you have been using, whether it's a gravity form to WordPress or whatever contact form or whatever thing they're using to collect data. This is what we're doing. This is why I'd be interested just hearing like what is that cell like? Cause as an ad tech, I would go out and proselytize WordPress back in the day. That very thing that is causing the technical debt you're trying to escape. But like, how do you go about communicating to a community in higher ed about digital transformation? Cause it's what you're doing, right? About APIs, but maybe never saying API, right? Like, I mean, I imagine you're not sitting and I'm talking to them about APIs. I bet you it's a very different discussion. What is that discussion? What does it look like? So there were two phases of discussion, I would say. And the first is in the product selection, there was no presupposition as to which low code tool that we would choose going into the project. Instead, it was really important for us to gather user requirements and figure out of the web apps they were already using, you know, what did that actually look like? What was their business process that was underpinning that application? And it's because we were able to have those conversations and do a detailed interview and analysis of each one that we were able to confidently say, okay, 80 to 90% of our user stories that we've collected over the course of this project can be solved by this one product right here. And it made us feel more confident in our selection of that product. As for the conversation that we had after the fact, once we had selected KualiBuild, I'll let Luke answer, you know, what some of that sell was like, those conversations during the, you know, the web app transition phase. Yeah, the answer is it depends. It depends on who you're selling to. There, I'd say, I've been on a bunch of projects that are refactoring old code bases and there's always a selling. There's always, at some point, you have to sell the fact that a feature is going away or somebody is gonna have to, their workflow is going to change. I'd say at Davidson, at least, the sales were a little easier. But it's, you have to go in with the approach of you are empowering them. That's kind of the salesman speak, is now you can make this update when you need to. You don't have to submit a ticket. You can do it and it will happen immediately. You don't have to wait for somebody to be available to edit your form for you. So you have to, I've at least approached the sales tactic of, you know, we're empowering you, we're giving you agency. You can change the text on this form. You can decide what, you know, who gets an email. Rather than, you know, and it's your removing barriers for them, rather than putting barriers in place. The hidden side of that is, well now you own this form and, you know, we don't wanna, you know, when you need a text change, please don't contact us. But I think when people are hesitant to accept that responsibility and accept the maintenance of their forms, you just have to be willing to help them along the way. You have to say, we will be here to support you for as long as you need. And for some of our people, we're gonna have to support them for every change until they're no longer at Davidson. And then maybe their replacement is feels more comfortable with the form. Some people just take what we've given them and run and they build their own, they build new forms with a start new processes. So it really depends, but I think the message is now you have the power and we've removed barriers for you. Yeah, and there's definitely some technical components as well that right out of the box with a modern SAS slow code solution are just streets ahead of a legacy ASP.net web app. You know, you're getting Azure AD single sign on out of the box. You're getting mobile friendly out of the box. You're getting accessible out of the box. You're getting a single unified Davidson brand out of the box. There, you know, other features we've leveraged are like group and role based assignment. So for example, hey, all those tickets used to submit to the IT department when someone would change jobs that you need this form to move from person A to person B because they left or have changed roles. Well, guess what? You could make that change if you wanted to yourself, but now you don't even have to because the software knows that the person in the manager of digital transformation role at Davidson as per our HR information system is me. So that's just a reference to that workflow item. It is not hard coded. So it's making people's lives a lot easier both on the empowerment front and just out of the box technical features front for sure. Can I ask a question? How ubiquitous is it? Like, is it just like the registrar in business orientated groups to use a term? Is it academic and is it sports and academics? And like, is it across the university? Do you have a specific slice of the university that you're really kind of working on and then spreading out? Like, it'd be interesting to see like just how ubiquitous the work you're doing is and where are those stories coming from? And what are the stories that you use to go to other groups and say, look at what they did. How could this work for you? Yeah, so the nice thing is that the web apps replacement which is kind of where we were starting was already spread across campus. We had departments that were academic. We had departments that were, you know more kind of service oriented. We had really high tech departments and low tech departments who all had these historic web apps that needed to be replaced by our low code solution. So they were kind of our starter seeds for creating that like widespread familiarity. And then what we've seen is that with those departments a lot of people who either interact with that form or hear from their coworker about that form that they start attending our training. And then that's led to like a relatively even distribution of engagement. I wouldn't say that we really have like any one area that has like taken it up more strongly than others other than us and we kind of have an obvious bias. One of the things that struck me when I was watching your discussion at UAPI and that kind of, I don't know. I mean, I go to the university API conference I've been going there since like 2015. And like I'm still kind of like I can identify with faculty and a lot of other folks because I'm like, what is an API? Exactly, right? Like what exactly is that? And what hit for me so cleanly when I was listening to you all talk about your journey and what you did is, well, it's not just web forms but web forms are really great use case around the campus to frame how data gets processed and then how it's used and then how you can kind of think through that more broadly and understand the API in relationship to a web form. And I think that does speak to pretty much everyone now who uses the web. So I really love that about your talk. And I wonder if you have some specific examples that you've been working on maybe related to the craziness that was the previous year where you can talk a little bit about this API journey in action and how you maybe as a group matured to the point where you weren't just R and D out there like there were on the ground missions that you could accomplish. Sure. So I can talk a little bit about the API journey broadly speaking and you were absolutely right that low code and web forms are a fantastic proving ground for API strategy. So as I mentioned, we had this integration platform SnapLogic that has allowed us to very quickly and easily generate all these integrations to retrieve data out of banner whether it be employee or student records EMS like our event management system or for buildings all kinds of different SaaS applications that have just sprawled over the last couple of years. If you thought the IT ecosystem was fragmented before the age of SaaS, I mean, you can see it now these platforms really help stitch that all together and present those integrations as little microservices that you can call from something like quality build or another low code platform. So, you know, we were really getting in deep with these microservices and creating dozens of them to serve these low code needs. But what quickly becomes apparent and one of the reasons that I think going to UAPI is so valuable is that that ad-infinitum create an integration for every single purpose and it only works for that one use case is unsustainable. And so what we've been working on lately is attempting to pull off some semblance of what BYU has done. And that is to create something like a college API that has endpoints for courses, persons, buildings, events, et cetera, et cetera. And now that we've spent so much time building in Kuali, we know all of the pitfalls of using an integration platform versus building our own properly managed, properly, you know, configured API platform. And even though we're still learning how to do that, it's become clear that like having proven this and having tested different versions of API strategy over the last couple of years, we now have a much clearer sense of the right direction to go compared to, you know, what we understood about this problem when we first started. As for things that we've been working on for the last year, Tessa and Luke can tell a little bit of the COVID story and how that ties into all things, all this stuff. Yeah, I'll take the initial part and then Tessa, do you wanna do the reporting aspect? Sure. Yeah, so I think JD tells the story better, but we were told 10 days before students were supposed to return to campus that we had 10 days to create an application to check in and track weekly student COVID testing. And we, I think we all cried for a little bit. And then after we were done mourning for the lack of sleep we were gonna have, we got to work. And it ended up being, and this is interesting because this was kind of the evolution of where we are with the API. It started out, we built a form in Kuali, very simple form to just student walks up to the check-in station, they tap their contact list ID on a reader. It reads that ID and then it hits this bespoke endpoint that retrieves student information. And that was done in SnapLogic. But we quickly realized the issue with utilizing SnapLogic is every single one of those calls is takes two to three to four seconds because with SnapLogic when you're running a pipeline like that it has to boot that pipeline and then run it. And so we began working towards optimizing that call by using SnapLogic to create a redis cache of all the student information and then using an Azure serverless function to be the endpoint that our form was calling. And after a couple of trial and errors, and I think JD did most of this work, but after a couple of iterations of that this response time is now down to 30 or 40 milliseconds. So those check-ins are really speeding along. And because of the success of that approach and how we realized why couldn't we use that approach for a true API, why can't we use SnapLogic to do a slow load of our data into a place that is not behind the campus firewall. And then use an API middleware to expose that to the campus. Yeah, and then capturing attendance was really just the first part of a significantly larger process. So a big part of what the institution needed was the ability to reconcile the daily attendance that was captured in that Kuali form with expected attendance. So all of our students were broken up into groups and they had required days to receive their COVID test on the results of them being tested once a week. So the university was looking for the ability to track compliance over time. And this started with the poor site coordinators, the people who were managing the actual testing site, like taking these two Excel spreadsheets, putting them side by side and like doing this manual comparison that took anywhere from like two to seven hours. And that was just not a very effective way to go about that process. So I designed another Kuali form that was called the COVID testing admin form and that was used to take in what group they expected to test that day. And that kicked off a process that we designed in SnapLogic, our kind of base-level middleware system that pulled in all of the information for students and groups that was stored in a smart sheet and reconciled that with the attendance for the day. And then that exported a data set that essentially said whether a student had tested that day and if they were supposed to or not supposed to and updated some compliance columns that we had in that original smart sheet. So a bit of a contankerous process, but it cut seven hours down to about 15 minutes from beginning to end of runtime. And that very final step actually circles back to the original Kuali form, updates it and uses some of the built-in workflow features to send out emails to a lot of our leadership members so that they get the summary sense of compliance for the day. It's interesting too, because I mean, what an interesting use case for a very particular moment in time, right? Historically, but that idea of seven hours to 15 minutes and the mission of digital transformation as a team, it kind of like it's a very brilliant example of what your team is working towards more broadly. And I think as I was doing this and why I invited you to speak is, I think more universities possibly are, but maybe aren't thinking through what it means to build a team like yours, to try and think through some of these issues across systems on campus. And I was really thrilled JD to hear that, after a process like this of low code and using other tools like SnapLogic or Kuali, that you're thinking, okay, it's time for us as a group to come together and start exercising a broader vision for a Davidson API that you start to build. That's super exciting. Yeah, we think it's about time. Again, SnapLogic has served us well, but we've found that if we had not gone through this Kuali build journey, we would not have realized the extent to which Davidson really needs something like a real time or a highly responsive standard Davidson API. It's not like the need for consuming APIs is going to diminish over time. It's only going to increase. And there are some areas technologically where Davidson continues to lag behind. For example, we have a mobile app, but it's a student administered and we definitely under-invested in it. So, okay, well, we wanna, Davidson wants to do a new modern portal, a new mobile app experience. How is it gonna get its institutional data? It's gonna get it from APIs. And if it doesn't get it from a modern API, it's gonna have to go to the integration platform and get it there and it's gonna be a suboptimal experience. So we really need to do this work now so that future projects, their integrations are enabled and made a lot easier than they otherwise would be. I wanna circle back to another thing Tessa said about that process. So there are other things that just going through the process of doing the reconciliation exposes to and being involved with the COVID process exposes to. So for the COVID check-in endpoint, the one that actually looks at the student information when they tap their card, that infrastructure would occasionally go down. So now we've started to experiment with how to set up postman monitors. And that's another thing that we picked up on by attending UAPI, the 2020 version. So Ken Lane, I guess the chief evangelist at postman was there and he talked a lot about monitors. He talked a lot about mocking APIs and we took that back and we drew on it when it came time to actually monitor this new real-time endpoint that we needed for the COVID process to be successful. For the reconciliation, we're now looking at the possibility of doing asynchronous integrations with Kuali because that reconciliation process even, it's a lot shorter than seven hours but even if it still takes 15 minutes to run, Kuali is sitting there waiting while the process runs in the background and sometimes it gets kind of upset that the web call that it made hasn't returned a result 15 minutes later. And that's because SnapLogic is doing all this processing in the background, but that's another thing we would not had to have explore if it were not for our involvement in COVID. And then like even strangely, it gets down to things like printing labels. We were volunteering on site fairly often and saw that students were taking forever to write their name and date of birth on the labels that would get adhered to the COVID test kits. So Luke and Tessa helped me set up this template that would, this template and this script that would get the list of students who were supposed to be tested, get their names and birthdays. And we went and bought a label printer, bought a bunch of labels. And I know Luke and I sat there for literally hours on end, printing and stuffing COVID test labels into envelopes. So it was both the technology component of that and the process component and just the hands-on to actually pull it off. So that's the power of a generalist team who doesn't have to be on ticket duty all the time or worry about computer replacements is when the institution has a need for something like this, we can be there even if it means stuffing labels. Yeah, and I love that idea that, you spoke about dutying now for the future because not only is that one of my favorite divo sayings, I think it's also a good, almost should be like the subheading of your team, right? We're dutying now for the future of data, Davidson. Because it's a cool project and I'm really fascinated by the formation of your team. I don't know if a team like yours existed at least in this incarnation. That I've come across, right? There's been a lot of focus at least in my field around ed tech and innovation and R&D, but I really am fascinated and intrigued by the way you all are marrying that with on the ground, proselytizing for business processes across campus that need to be rethought. So it's a super cool one. I really appreciate you all being here with me. Yeah, glad to be here. Thank you. Right? Thanks again. All right, thanks, everyone. Mm-hmm, mm-hmm, mm-hmm. Om nom nom.