Altai Otgonyin, Mark Williams Low-code + Banner Altai Otgonyin, Mark Williams motgonyi@kent.edu

Agenda Current State What Was Before Why? Lessons Learned Looking Forward

Baseline Banner setup. SSB and Admin Pages (also INB) access the database and make updates.

Overview of the current OutSystems architecture. The apps need at least basic data from the EPR (Banner), most make use of more specialized data, such as employment and financial aid information in the case of Tuition Waiver (benefits) app To make these integrations reusable across applications, we have created libraries providing this information as Core Modules, the app developers then do not need to learn Banner intricacies and can focus on delivering a great user experience. To further isolate the core modules from the data source as well as to access the Oracle database, we make use of extensions.

Looking at the architecture of our “legacy” applications, here legacy meaning that they were created before OutSystems and are built in appropriate technology stacks for their time. Most applications are kept up with bug fixes and other, usually minor, enhancements. At the time, we built a set of Web services to provide data to the applications. However, due to the somewhat consumer-app-specific data models and Banner artifacts (e.g. views, tables, stored procedures) these ended up being not as shareable across apps as we would have liked.

Looking closer at the internals of a the web services we see that a lot of items necessarily are duplicated across them, as each one is technically a different .NET or Java application.

But wait there’s more! The real overheard, as far as duplication of work, comes in the logic portion. Where the service provides the type of data to the application(s). Each application at least needs general person information to display the currently logged on person’s name, as well as to verify their roles. Over time, the definitions between the applications (and their data provider web services) could sometimes drift apart. Resulting in situations where a “student” in App 1 was a different population than a “student” in App 2.

Coming back to the current architecture. Now we will look at lessons we’ve learned and what improvements we are planning to make.

Taking a closer look at a core module, in this case the Student one, we see that it contains a selection of Student related concerns (data models, actions) While this has worked until now (~3 years on OutSystems), we are noticing that updating one of these rather large modules is expensive. Expensive in terms of verification (unit and functional testing), and expensive in terms of coordinating the change while multiple projects could be actively using this modules. Verification of the entire module is required when one of the components is updated, to verify no regressions took place.

Solution is to break up the large Student module into a more granular set of Core Modules, each dealing with one aspect of the student. Example: a core module that provides the student account balance, which can be independently updated from the module that provides the student’s currently registered courses. This is currently in progress

In the near future, we’d like to move away from having OutSystems be a data provider to other systems, as we have dedicated tool for this purpose. This tool is Talend. Not only does this provide web service integration, its other features include functionality like University-wide data models, a caching layer, governance (Data Stewards approval tracking), and reporting on how the data is being used. This also frees up resources in OutSystems to build more apps 

While the first step is to make Talend talk directly to Banner, as the core modules used to in OutSystems. Ethos is slated to be the correct way to integrate with Banner. We are envisioning this integration to be a mapping between Ethos data models to the models built in Talend the rest of the systems use.

Questions?