Joe Gottlieb: 0:04
Hello, and welcome to another Higher Digital podcast. My name is Joe Gottlieb, president of Higher Digital. And today I'm joined by Jason Pyle, our vice president and principal consultant of digital integrations and architecture. Welcome Jason.

Jason Pyle: 0:20
Thanks Joe. Thanks for having me today. What do you want to talk about?

Joe Gottlieb: 0:24
Well, I had a chance to review your presentation from cohesion last October, and I really liked the way you described enterprise integration architecture as a foundational success factor for digital transformation. But since both of those topics are so complex and , uh , and their relationship can be tricky. I thought we might, double-click on several of the key concepts and identify some traps to avoid because at the end of the day, architecture work is hard and institutions are, are they , they are looking for best practices and shortcuts, wherever available makes sense.

Jason Pyle: 1:04
That does , uh, I give these talks all the time. I really enjoy them. So I'm looking forward to talking today. Cool .

Joe Gottlieb: 1:12
All right . Let's start by setting the stage. Why is enterprise integration architecture so important to institution success and why is it so often neglected?

Jason Pyle: 1:24
So let's start with , um, this notion of institutions undergoing their digital transformation. Um, and when I define digital transformation, I typically typically use definition of change in people, processes, and technologies to enhance the customer , um , or your student and faculty staff experience. Um, as you're , as each institution figures out what their digital transformation looks like. Um, it often involves investing in more software , um , and more best of breed solutions that provide a really good customer experience at your institution , uh, when you're investing in these different, best of breed solutions , um, they each typically have an integration component because you want , uh, those solutions , uh, connecting to the SIS or other systems in order to pull data in real time or near real time. Um, the challenge is if you don't do these integrations correctly , um, and you stick to a point to point world , uh, these integrations can come , uh, become very complex and fragile and extremely hard to maintain. Um, I read a McKinsey survey that says , um , when companies are all in, on their digital transformation, the number of point to point integrations actually rises , uh, about 50%. Um, so think 50% more set your institution. Um, at the same time, the survey said the reuse of services actually decreases. Um, as you're investing in these new technologies, you're not reusing services, rather you're building more point to point integrations. And so while you might be doing great things , uh, uh, at the customer experience level, not taking care of your integration architecture can lead to those integrations, being very, very expensive to maintain , um, and really can lead to maintenance problems that you have on your backend . And so, as we look at digital transformation and the investments your institution wants to make, we want to make sure we're integrating in the appropriate manner so that these integrations stone end up being too expensive to maintain for your institution.

Joe Gottlieb: 3:55
Hmm . Fascinating. So, so what happens when institutions neglect to make these investments or make these investments too late? Have you seen that? Is that a recurring problem? What happens there? Yeah ,

Jason Pyle: 4:06
Yeah . That is very typical in higher education. Um, uh, even the smallest of institutions , uh, have at least 20 or more point to point integrations on campus and , uh, at larger institutions that can easily raise up to a hundred, 120. Um, and what happens when you're maintaining these point to point , integrations is as you upgrade software, you're no longer just upgrading that piece of software. You're also upgrading the integration between however many pieces of software integrate with that component. Um, and that , uh , ends up being challenging in terms of keeping pace with, with updates to the software, introduced the new software , um, and really maintaining your integration architecture and keeping all these integrations working on, on a daily basis. And so as we're investing or as institutions are investing in more , um, more best of breed solutions , uh, you're just adding more and more integrations. And if you keep going down the point, the point world , um, it just ends up being cost prohibitive . Um, and what I see at a lot of institutions right now is they know they need to make a change. They know they have a big challenging, architectural issue on the back end . Um, but they're almost , uh, frozen with fear and don't really know how to get started. Um, they just know they are spending a lot of money , um, in upwards traditionally of $250,000 or more simply maintain their existing integrations. And that's a large chunk of money that would be better spent , um, enhancing the student experience for example. And so , um, when you're , uh, investing that much in the integrations and they're still as fragile and brittle as they are, this can , uh, pose maintenance challenges , um, cause technical debt , um, and really lead to issues. Um, simply keeping your software up to date and talking to each other.

Joe Gottlieb: 6:32
Yeah, this technical debt is a concept we like to be really clear about. I think it captures at the, for a technologist , at least this notion that moving forward gets more costly, more risk prone, and actually tends to be slower when you have technical debt holding you back. And so this technical debt, I think we like to describe it as when you do something kind of quick and dirty in the, in the, in the spirit of velocity, but as opposed to the right way, that's going to be in the spirit of scalability and, and maintainability, right? You wind up with technical debt. And so as technical debt accumulates, as you just said, you know, things get more brittle , um, things get slower, things, get more costly, things, get harder to administer even the visibility into what all these systems are and all their payer pair-wise combinations right. Gets really hard to manage. Um, so that seems like a pretty good motivation to avoid this. And yet I know we see institutions struggle to , um, make the commitment to this discipline. So given that, you know, we know what's important, but it can be elusive, so help help our audience with some different approaches they might take to integrations and how you might distinguish one approach versus another.

Jason Pyle: 7:59
Yeah. So , um, uh, what you said makes total sense. It's exactly the problem set institutions are having. Um, and I would even go as far to say that each point to point integration that you're adding, you're just adding to that technical debt. Um , uh , and many institutions are trying to figure out where do I get started? How do I prioritize things? Um, I can't go and rewrite all 50 integrations I have on campus. Um, so which ones are the ones to look at first? Um, and what I always tell customers is look at the ones that impact the student experience the most. Um, when you look at today's , um, uh, students , um, with their mobile devices, they expect everything to be front and center on a mobile device when they want it. Um, and the past , um, going all the way back to when I went to school , um, institution Scott away with saying, Hey, you paid your bill, take a look at it tomorrow after things update tonight , uh , that is not what students expect nowadays. And so I even tie integrations into , um , the student experience because somebody else, some other institution is going to provide that in near real time. And so the big thing is looking at those , um, those systems that impact the student experience the most. And as you're looking at them, you want to see which ones allow you to integrate , um, rather than flat files , for example, in batches, to do it via API APIs. Um, if you find that right integration , um, that leverages API APIs , uh, and , uh, really hits on the student experience , um, that is a great place to begin and where you start building the services that are reusable , uh , across your ecosystem. And so, for example , um , when you're connecting to your SIS, all the major SIS is typically have a pretty decent library of API APIs. Um, and so pretty much every integration that's out there, once something from , uh , about a person, whether it's their first name, last name, phone number. And as you look at these API based integrations, you start looking at what services do I need. Um, and a good starting point is the person service. I know a lot of different things need the person service. And so you leverage that API , uh , that hopefully your SIS vendor has provided , um, to provide a single way of getting persons data from the source. Um, and rarely as you're building up that first integration, you look at all these different services and, and make sure that they're available as a service. Um, granted you're only working on the first one, so it hasn't been re-used yet, but as you get through the first one and look at the one after that, the second one needs person's information. Well, I don't have to go and figure out how to get it from the SIS or the authoritative source. I can just reuse that , um, that service that I had previous previously built. And so as we talk about getting out a point to point integrations , um, paying down technical debt, rather than just adding to technical debt, the use of reasonable services becomes a very important piece of your integration architecture. And so by looking at something, that's going to be a big win for the student experience that has these API based services. You get your start of , um, building , uh, uh, integrations that are more API based, more hub and spoke based rather than the traditional point to point integrations that , um, any it member at any institution knows and , uh , we'll have , and has worked with.

Joe Gottlieb: 12:25
So let's do a quick , um, some quick definitions here. So API APIs, application programming interfaces, right? These are, these are, I like to think of them as higher level abstraction services that let you think about oftentimes business oriented services. You, you mentioned the , the , the person service. Okay. So like, okay, I can, how do I interact with people in the system identities in the system, so to speak, right. Um , contrasting that with flat file integration, which is really about kind of a brute force, typically, you know, sort of field mapping exercise, where you're just dealing with the, by field in a database differences from one system to another, so much lower level, but tend to be the mechanism you would use if you were really trying to brute force and , and connect sort of all layers, all mechanisms of , uh , of a, of a system to another system you'd want to figure out, okay, what do we, you know, what are all the data fields behind person services, as an example, what are all the Dale bit of fields behind , um, you know, certain, you know , uh, operations that are conducted on the persons in the system, et cetera. Right. So , um, and like you said, API APIs don't necessarily have to be industry standard to be reusable. Just the fact that there are higher level abstractions than deep field mapping gives you a higher leverage point. Is that, is that a fair way to contrast the two?

Jason Pyle: 13:59
Yeah, that is fair way to contrast the two. Um, and as you said with point to point integrations, they're very low level, they're getting at the database , um, and you're kind of mapping database , uh, columns or fields from one system to another. Um, the challenge with these point to point integrations, in addition to having the learn, the schema of , of these systems is you have to learn the technologies on both sides. Um, so for example, if , uh, you had an Oracle database backing your SIS and another vendor had a SQL server database, well, you better be experienced in both Oracle and SQL server to figure out what fields and what tables and columns , uh , you want to get out of that Oracle database and put into SQL server database. Uh, and, and with this comes a lot of challenges in working with business users. Um, the it staff will be looking at the name of an attribute or column, and the database business users know that they just want, for example, first name and last name. And with these API APIs that a lot of vendors , uh, uh, offer up , um, most of them are in business terms and that actually enhances the communication between , uh, the it technical staff and the business staff. Um, because now you're looking at what that put of that services. Um, and immediately everybody's speaking the same language. The, the business staff can understand, Oh, that's first name because that's how it's labeled and the it staff understands it too. And so you're not trying to , um , kind of do a translate between what the, what the column is in the database with what this a business user actually mean from it. Yeah,

Joe Gottlieb: 16:01
It's , it reminds me of some past war stories, right. Where when you're dealing with flat file or dealing with point to point, you're dealing with, you're not just dealing with the different systems, be it let's say Oracle or SQL server, you're dealing with the often not arbitrary, but very expert and contextually driven naming convention for database schema that are employed by whoever built that system. Right. And so, so now you've got, you've got the system , uh, constructs that have to be learned. It might be a bit different from one system to another one database to another. You've got the schemers that have , could use this labeling. And I'm so glad you shared that. What you've observed over time is that API APIs having been developed with an evolution of all this craft, right. So sort of the more recent , uh , uh, uh, um, invention than some of this lower level stuff , um, have come with better naming, better labeling, more intuitive , uh, documentation. So that business people and I, and technology people can stay on the same page really, really useful. Right?

Jason Pyle: 17:08
Yeah. Very useful. Um, traditionally you would have been looking at a table name and an attribute that , um, unless you knew the database, you didn't really know what it meant , um, especially as a business user. Um, and now that these API APIs are being built and are focusing on the business domain, as opposed to the backend technical domain , uh, that really allows , um, each side to talk the same language and focus from a domain perspective. What's important to that domain is at first name. Is it last name? Do you want an address we're talking about of birth , um, versus really trying to translate back and forth of, well, here's the column in the database? The business person says, well, that's meaningless to me. Um, and then you have this long conversation about, is it the right attribute? Um, and this takes a lot of that away. Um, and so even in addition to , um, uh, getting a reuse of your services, this is also going to make , um, requirements gathering and figuring out what you're going to build , uh, that much easier than it would have in the past for point to point integration.

Joe Gottlieb: 18:29
I think , I think it also contributes to that , um, overcoming that, that sort of fear of change, right. I, you know, what happens when this, when this knowledge is so esoteric or rooted in the proprietary nature of these schemes , because so few people in the organization can participate in the problem solving, right? And so you become behold not only beholden to the small group of people, but the general confidence in an organization to ability to make change happen, goes down, right. It's like, it's just, it just seems so foreign. Um, and probably I'm sure that obstructs progress as well. Now you've mentioned point to point, and you've mentioned, you know , I think you mentioned hub and spoke, so can talk me through the trade-off . So, you know, there's gotta be something good about point to point. Otherwise it wouldn't be done so often. So help me with some of the positives and negatives, so we can all better understand the trade-offs of these two approaches. And ultimately I'd like to get to a place where we help guide our , our audience toward , um, the right kind of approach.

Jason Pyle: 19:34
Sure. Um, so point to point isn't necessarily all bad. Um, uh, it really is a what I'll call quick and dirty way to get an integration done. Um, and so when you get a new piece of software, if they offer point to point , um , integrations, I say flat file. Um, it, I won't say it's easy because just not anything with integration, that's easy. Um, but typically your fastest way to get to production is through a point to point integration. You're focused just strictly on these two data sets and , um, pretty much every tool out there allows you to easily create like a CSV file, for example , um, the challenge with the point to point, and, and we've really talked, talked through a lot of that is , uh, is you need to understand both sides of the technology spectrum. Um, you need to make sure that as you upgrade one system or another, that you upgrade that integration. Um, and then really the other problematic thing is it's not in real time. Um, and we'll kind of dive into that a little bit, a little bit deeper, but , um, typically these batches run , um, every two hours or four hours, or even up to every 24 hours. And what that means is as you do something in one system, it's not reflected in your main system or vice versa for up to 24 hours. Um, and that really affects the student experience. Um, imagine, say , uh, if you went to Amazon and you ordered something, they said, wait for 24 hours before it shows up in your orders list, because we have to get the data to sync . Um, you know, it'd be crazy to do it that way. Um, and that instantaneous feedback is what are , what students want nowadays. Um , and so with point to point integrations, you really can't get to that real time or what I often call near real time , uh , method of data exchange , uh, with hub and spoke. Um, what I would say is hub and spoke allows you to reuse your services , um, and, and you pass them all through the central hub and your different applications or spokes on that hub hub and spoke, promotes reusability. Um, and so what I mean by that , uh, is we've built that person service when I call the hub to get that person. Um, I get that same person, no matter, no matter what, and no matter what system I am . Um, the other thing hub and spoke is really useful for is , uh, is abstracting your integrations. And so suppose I have this person service , um, and I want to swap out the system that , uh, that's providing those people as long as I adhere to the same API spec that I was using before it's abstracted out. So , uh, everybody downstream doesn't need to know you swapped out, swapped out systems. Um , I know that's kind of an unrealistic point of view when I talk about persons in an SIS. Um , but think of more of your best of breed solutions , um, they, they might provide data. Um, for example , uh, a housing application might be authoritative for housing assignment data. It's a smaller app. It's more easily switched out, but as long as you follow the API that you agree to for the housing assignments , um, nobody's affected downstream. Whereas if you were in this point, the point world , um, and you switched out your, your housing application , um, if you have 10 different systems that connect to it, you're talking about 10 different point to point integrations that you right away have to rebuild to implement that application. And so with the hub and spoke , um, while, and what I'd say , um, one of the downsides is you have to spend the time to build up these reusable services , um, uh, depending on how much the vendor of that application provides. Um, and so it might be more time , um , and more planning on your part, but in the end, the benefits are realized by everybody , um, uh, in terms of , uh, terms of reusing those API. Um, but also having that level of abstraction, we all know how quickly technology moves on a day-to-day basis. Um, and you want to be able to provide whatever the best solution is for your users. Um, and so while point to point quick and dirty, and really the fastest way to build an integration, hub-and-spoke really sets you up for the future, allows you to reuse services, allows you to abstract out those integrations and really lays the foundation to actually bring down the maintenance costs of those integrations as you migrate them to a hub and spoke model.

Joe Gottlieb: 25:29
Okay. So , um, let's, if we contrast those two , um, you've got their , their respective trade-offs, what does a hub and spoke sounds to me like there's dependency upon, let's say extreme standardization of services, right. And so , um, is that a practical thing? And so what do you find in practice in terms of the ability to get to a single hub that serves all spokes with a completely normalized set of services? Cause that sounds a bit utopian. Um, and I imagine the reality is somewhere in between pure standardization and , um, you know, the , the pure point to point commentorial explosion of , um, of sort of the , the , the , the field mapping exercise of , um, of direct point to point.

Jason Pyle: 26:27
Yeah. Um, definitely, as you said, it is utopian , um, I've, I've not worked with a customer who has everything 100% running through hub and spoke , um, with that being said , uh, as he prioritized , that's why I say pick up the things that impact the student experience the most , um, as a starting point. Um, but it is really challenging to standardize on everything. Um, it does take a lot of time if your vendor doesn't provide API APIs, it could be a huge challenge to try to build them , uh , yourself. And quite frankly, not every vendor is ready to move to an API based integration. And so , um, uh , I won't say that point, the point integrations are going away or flat file integrations are going away. There's plenty of vendors that still rely on that. Um, but , uh, you can really come up with a good mix of the right tools and the right level of standardization , um, in order to find a solution that works best for your institution.

Joe Gottlieb: 27:46
Okay. So it sounds then like the ultimate best practice, knowing that pure hub and spoke is , um , would tend to be impractical because you're going to have a mic . You're gonna have a portfolio of technologies , some more mature than others. Um, and there may be requirement where you really do need the quick and dirty, direct integration, even if you're willing to throw it away later. Um, and I've what I've heard also about from point to point, integrations is they can be the best way to get to the, sort of the deepest preservation of value , uh, sort of specificity of a , of a type of transaction that the two systems could accommodate. And therefore is less , um, exposed to the least common denominator effect of a , of a completely standardized set of services. So, given, given all of that , um, it sounds like a hybrid approach is what is ultimately required. And so how do you, how might you help our audience think about really managing their integration architecture as a portfolio of integrations that are, that are constantly evolving , um, and, and trying to exert maximum leverage via reuse wherever possible, but coping with the extensions needed to do the things that need to be done in the absence of available APIs or standards. Does that, am I describing that, right?

Jason Pyle: 29:08
Yeah. You, you really are gel . Um, uh, and , um, one thing I failed to mention in the previous question too, about point to point integrations is they have their place. Um, if you're , if your integration it's changes a lot of data back and forth , um, then flat files could be the fastest way. Whereas an API based integration might take the entire night as you call them, call the API APIs on more of a transactional basis. And so you will end up with that set of mixed technologies. Um, I think as, as institutions looking at things , um, th the first place to look is what does your vendor provide? Um, uh , so for example , um, Ellucian provides the ethos platform, which is , um, uh, doesn't cost any extra maintenance and provides a hub and spoke platform for that institution to use. Um, and I know other vendors provide some other vendors provide similar capability. Uh, I forget the name of Oracle was integration engine, but they have something similar , um, as does campus nexus or anthology and a few others. Um, so first thing is what does your vendor provide , um, that might make this jump easier? Um, does your vendor vendor provide a lot of API APIs that you won't ever have to rewrite and rewrite ?

Joe Gottlieb: 30:45
Sorry to interrupt by vendor where we tend to be talking about SIS as like pretty much the central system that institutions are utilizing. Right.

Jason Pyle: 30:54
But also really any vendor. Um, so in the case of that housing application, that that might be authoritative for housing assignment data, does the vendor provide an API so that I can get that data, or does it force me into going the flat file approach? Um, so we talk a lot about the SIS is kind of the central hub. Um, but the rules I'm talking about in the situations don't really , uh, really do apply to other systems and not just the SIS. And so , um, a great place to start, as I was saying, is look at the foundation of, of what your , um, what your vendor provides , um, for the ones that provide hub and spoke. What is exactly what features and functionalities does it have? Um, and, and each of these hub and spoke , um , kind of platforms provides a different set of functionality. Um, and really the first thing I look for is really two messaging patterns as you move to near real time integrations. One is something that , um, is really a synchronous messaging pattern where I can call the API and I will get a response to that request for the API. The other is , um, what I call published, subscribe , um, can my product publish a change , um, and send it to subscribers so that they become aware of that change. Um, and so it's looking for those two messaging patterns, and then depending on how complicated your integrations are, there's other products you can either use on their own and not even use , um, your vendor provided platform or that you can use to augment the platform. Um, and so, and what I'm really talking about there are enterprise service buses or ESPs. Um, they provide a lot of functionality. They will , um, help provide hub-and-spoke , um, uh, integrations. Um, they will be able to , um , provide a service catalog of all the API APIs that you have. And the one additional thing they do really well is , um, and this goes back to standardizing on a data model, is they do data transformation really well, and what I call on a no-code or low-code way. Um, so as we talked about standardization and having these API set a reusable, that doesn't mean every other is going to talk the same language , um, or understand the same API call. And so data transformation becomes a really important part of a hub and spoke model. Um, and traditionally you might've written little programs, a little Java app or dot NetApp , um, uh, that would do this, but with , uh, where enterprise service buses are now and the functionality they, they can provide, sometimes your data transformation is just a matter of clicking and dragging and dropping a couple of things. Um, and so there's a lot of different approaches to integrations and what products you use. Um, but typically it is a big mixture of hub and spoke and flat fire point to point integrations.

Joe Gottlieb: 34:43
Gotcha . So I think that was really helpful, right? Because you, you, first of all, there's a , you look at the systems that you have and SIS has one, but not theirs . There's lots of systems that are typical in a higher ed portfolio. And so really taking some inventory as to the API APIs that are available across your basket of systems that you've wound up with in your portfolio, and then considering , um, more, either higher ed focused and, or even enterprise generic, like I think a MuleSoft comes to mind, right. But a variety of enterprise service bus type players that could either replace or augment , um, the efforts that you make in a hub and spoke approach with your portfolio of systems. Right. I like that. That's a , that's a good, good set of things. So then given that landscape, you know, let's talk about, that's the sort of the architectural view . Let's talk a little bit more now about development. You mentioned low-code no-code, but I imagine there's still some coding involved here. What, what in your mind is the , one of the bigger trends that's helped push this along in terms of making enterprise integrations , uh , easier to tackle anything on the development side?

Jason Pyle: 36:00
So I think the biggest trend that's making them , um, making this more and more practical is the proliferation of API APIs that these products are , uh, are now providing , um, typically this day and age , um, if you're building a new solution , um, it's almost an expectation that there are API APIs available for you , um, and there , and , and the nice thing about API APIs, particularly the API APIs that are restful and face-on based is that every major development tool really allows you to take a chase on message. And Jason's just another data format. Um, just like XML is a data format, but they can take a Jaison message and immediately produce it in say, Java objects, dot net objects without writing a whole bunch of hand parts and code. Um, and they can do the opposite thing, take these Java or.net objects , um, and turn them into the Jason strings that get sent over. And so the API is being available coupled with restful services. Um, Jason based that , um, with restful they're based on HTTP semantics , um, uh , so for example, an HTTP get means you're reading data of post means you're creating a put means you're updating , um, it's made these API APIs much, much easier to use , um, uh, much easier than the traditional say soap was still based API APIs. Um, and so with these new sets of restful API APIs, the ease in which you can use them , um, and the , the lightweight data format that most everybody is using , um, and the restful API APIs , um, that combined with all the, all the tools that you're pretty much every major , um, uh, development language provides. Um, they've really lowered the barrier of entry into building API APIs or into consuming API APIs. Um, I remember doing soap based API APIs and , um, and they were even worse if you actually wanted to encrypt the envelope and Senator cross the wire, it would take hours just to get that encryption , um, with , uh, with restaurant HTTP , um, you just use the same semantics, any website uses it's just HTTPS . Um, and so even on the security front, in terms of encrypting these things, you have a much lower barrier of entry. Um, and I think that's really, what's allowed people to , um, to really between the tools and , um, the types of API it's really allowed it to explode. Um, and when we talk about these types of API APIs , um, realize that people across the entire tech industry are using these types of API APIs. Um, Facebook has a bunch of restful API APIs . Twitter has bunch of restful API APIs. Um, really the tech industry is globbed on as this is a straightforward, secure , um , uh , much easier way of doing integrations via these restful API APIs.

Joe Gottlieb: 39:40
Uh , it's , it's a great reminder of that. The broader technology industry has found well , it was, it was confronted with a great need for acceleration of development of new capabilities, right. And scaling of those capabilities. And, and , uh, you know, remember the object orientation slog that, you know , w took decades, right? But ultimately I think got unlocked with some of these massive opportunities to create massive businesses behind this scalability. The beneficiaries are, you know, for sure all the enterprises in every vertical that they're seeing , um, better architectures from their technology suppliers that then allow them to probably have higher levels of abstraction, of reuse of services as they build , uh , a capability of, you know, an integration architecture that spans their portfolio of systems. And then with this development techniques, like , um, you know, Jason arrests just simplifies even further the way that we can incorporate services into , um, our applications and our data. You know, it reminds me this whole effort on, on integration architectures, you know, reminds me of the constant refrain we have about avoiding customization in packaged SAS offerings, right. Software as a service offerings, like these enterprise applications that we adopt, you could either customize deeply for your own direct needs. It feels a bit like point to point, right? Like, you know, a point to point association with your requirements, or you could take on more of the mutually agreed standards and levels of abstraction of services and reuse , and look just to configure maybe the nuances that are going to help you be different. Is there a parallel there that we can draw?

Jason Pyle: 41:28
Yeah, I do. I do think there is. Um, and so even if you take it to start talking about custom and custom API APIs , um, that also means that you're really tied to that vendor , um, and a wide variety of ways. Um, you have this custom code , um , and this custom API, you have to manage all that custom code as you apply updates. Um, but you've built something that is , um, vendor specific , um, that ties you to that vendor. It can't really be used elsewhere. Um, and even if you wanted to swap a vendor out, you're likely going to have to rebuild whatever those customization are, especially if they're separate applications , um, in order to do that. And so when you think point to point, as compared with , um, and layering and custom API APIs, it really does kind of become a point to point integration. Um, you might actually have that hub and spoke layer , um, but you're tightly coupled to that vendor at that point. Right . Um, whereas with rest and, and Jason and , um, standards-based API APIs, that's really where you talk about reusability. Um , you talk about abstraction , um, and you're really hidden. And quite frankly , uh, with a SAS application, you're going to build faster. Um, it's going to be much more maintainable. You're going to easily stay current. Um , and you won't have a lot of the same challenges , um, with , uh, say a custom API that really locks you into that vendor.

Joe Gottlieb: 43:24
Right? And so that's just that translates to massive benefits because if you avoid the temptation to go off the reservation, so to speak and to do your own thing with customization, you get the benefit, not only from a less brutal , uh , requirement for your own changes, but when your suppliers are making improvements, you can actually adopt them because you're not stuck with a stuck on a previous version that your customizations have been mapped to that maybe aren't going to map to the new version because you've departed from things that they've agreed to hold sacred right. In the API set. So , um, that's, I think that's some great practical advice for our audience in a, in a few minutes that we have remaining Jason, I know this is hard and you've done a great job of, of demystifying some of the moving parts, but could you share in at least a few minutes , um, at least one success story where an institution you've seen, that's made some great progress here and proven in some of these methods , uh, and then translate it to their own, their own ROI, so to speak in their own velocity , uh , using these concepts.

Jason Pyle: 44:33
Yeah. Um, so I've done a lot of work at , um, Southern New Hampshire university. Um, they are an Ellucian customer , um, and , uh, they, they just had this plethora of integrations that they couldn't maintain , uh, uh, I mean, hundreds of them. Uh, and so they made the conscious decision that we want to revamp our integration architecture that , um, as the university explodes and gets bigger and bigger, that it couldn't keep up with what they're doing with all these point-to-point integrations. Um, and so at Southern New Hampshire, they were an Ellucian customer. And so they utilized the Ellucian ethos platform , uh, and all of the API set Ellucian provided , um, but then layered MuleSoft on top of , uh, ethos integration. Um, and so , uh , there were certainly things that ethos couldn't do or their vendor platform couldn't do that MuleSoft kind of augmented it. Um, so for example, going back to data transformations , um, they're now able to use all their data transformations within MuleSoft. They're all managed in MuleSoft and they get the benefits of that low-code or no-code. Uh, another example is , uh, that published subscribed was really data got published in the subscriber, had to come back and get that look for that data, say every 30 seconds. Um, whereas they leveraged the ESB to actually deliver that data to the systems that, that really wanted those subscriptions. And so it really made it a true published subscribe in that the subscription was published or that yeah . Subscription was published to the vendor. Um, and so those two combinations really accelerated , um, Southern new Hampshire's integration strategy. They went through the legwork of, of really building this and getting the right services offered , um, uh, and leveraging MuleSoft and ethos the right way. Um, but now what they have is the added benefit of they can now build their integrations faster. Um, so if you think about, we always go back to the person's state of model, if you go back to the person's data model and you need to build an integration , um, they have that reasonable service and their integration really just becomes a data transformation and MuleSoft that I might not even have to write any code for , um, versus having to go back to each system and figure out which database columns I need , um, to produce a flat file that can then be sent , um, sent onto the other system. Um, and we've done a lot of interesting things , um, uh, and actually leverage , um, at Southern New Hampshire leverage , um, the hub and spoke model for flat file integrations . Uh , and so , uh, included in the integration strategy now , um, is , uh, is a data Lake. Um , that data Lake stays in a data Lake built on Microsoft dash , or that data Lake stays up to date with all the subscriptions from all the different systems that, that it subscribes to. Um, and then we layered , uh, uh, um, what I call an I-PASS vendor on it. Um, this I-PASS vendor , um, was very quickly able to extract data from Azure and format it into a flat file. And so , uh, so they even want that next step further. Um, and now they can generate flat files in a fraction of the time , uh, as if they were using another tool. Um, and then really the big added bonus , um , that they got out of it is now are using that data Lake to look at operational and enterprise reporting , um , including the data warehouse. So it's been a really big success story. Um, uh, there's , uh, uh, Google Snoop bus. I bet you can S Nhu dash bus. I bet you can find a presentation on it, and I'm not suggesting everybody has to go to that length. Um , Southern New Hampshire had a very complicated system with , uh, a lot of different other systems that were homegrown , um, built by contractors, third parties. Um, and for them, this was a problem. It was stopping them from expanding their business. And so they made that investment. Um, but each institution can figure out what makes sense for them, what makes sense for their budget and staff , um, and come up with a way to , uh , redo your enterprise integration architecture, to realize the benefits of reusability maintainability , um, uh , without sinking , um, or , uh, investing as much money as say, a Southern New Hampshire did

Joe Gottlieb: 50:18
Well. That seems like a good point to end on so we can let our audience get on with improving their inner prey , enterprise integration architectures. Thanks so much joining me today, Jason, and , uh, and thank you for having me. You bet, and thanks to our guests for joining us as well, be on the lookout for our next coffee talk focused on a challenging 2020, and look to what the future holds in 2021 in the meantime, have a great day and hosts , and we'll look forward to hosting you again at the next higher digital coffee talk, take care.