We continue our modernizing the Higher Ed ERP journey by taking that dreaded look at the many customizations made to your environment over the years. We’ve already discussed how we got here and the need to clean up the data within the database before you migrate. Now we’ll look at the rest of the environment…

We’ve all heard some variation of the following: “Return to Baseline” or “No more customizations” or “You can’t do that in SaaS.” While these words can send a heavily customized Banner institution into a defensive tailspin, everyone needs to review what they have at one time or another.

There’s a time in the lifecycle of every piece of code when it needs to be reviewed, reimagined, and possibly retired altogether. Constant maintenance and modernization are part of a vibrant, living, breathing ecosystem. In a world in which decision makers expect immediate access to dashboards, charts, quick looks, and summaries with real institutional consequences, we can’t afford a cluttered database. It’s time to clean house.

What does this mean? That depends on how well-organized your IT development has been for the past 20 years — and how well those who developed customizations documented the changes. I’ll pause a moment here while you pick yourself up off the floor from laughter… All better now? Let’s continue.

For the institutions that are well-organized, walking down a certain directory path will find all custom jobs that have ever been written. If you’re lucky enough to have developed a Git repository to store all your customizations, you’re ahead of the game. You already have a catalog of content that can be easily digested and tracked. Nice job; you’re not going to have a problem compiling a list of all (or many) of the customizations that need to be reviewed.

However, if you’ve been less organized and have things haphazardly spread across multiple systems and locations, you might want to crawl under your desk now. When you decide to rejoin society, you’ll be happy to know that all is not lost. There are things that can be done to help identify many of those customizations.

Ellucian has developed utilities to help identify customizations within known directories. If you’ve been part of the Banner Technical community for a while, these may sound familiar. I would encourage further investigation, as they will assist in identifying objects that have drifted away from baseline. There are two jobs that have been mentioned in passing, and there might be a bit of confusion as to what each one does and does not do.

Blueprint Utilities was the replacement for the Banner Environment Compare Tool (GURBCTR) which was removed in the General 8.18. This process will scan the code tree and database to compare against known baseline resources. While this process contains the original scanning tool, it can also be modified to run manually against an ODS environment. This utility can run directly from ESM or manually and can take several hours to complete. This process will attempt to automatically upload the output to Ellucian if port 443 is open for outbound access.

Modernization Studio Scanner (MSS) is a tool to help institutions identify custom and modified objects within the ERP environment. Like Blueprint Utilities, it will query the code base and database objects but is also designed to scan designated third-party environments (Cognos, Appworx, ODS) to extract configuration data and statistics. This process will also scan application war directories and cron configurations. As this process runs in multiple steps, once all tasks are complete, all results can be zipped and manually uploaded to Ellucian for review. MSS must be manually downloaded and run; it cannot be run directly from ESM, except for Beta clients.

The question becomes; do we need to run both jobs? Technically, no. MSS has all the same capabilities as the Blueprint Utilities minus the automatic upload. The recommendation, however, is to run both if you’re actively engaged with an Ellucian Sales Account Executive. Since Blueprint Utilities has the auto upload feature, Ellucian can get a jumpstart on the current state of the environment. That can save critical analysis time while sales finishes their business.

How do these tools know what’s baseline and what’s not? Every known Ellucian object (table, column, index, page, war file, SSB jar file) is reduced to a checksum or a series of checksums. If the checksum of the similar object in your environment is different, it will be reported as a drift from baseline. There are built-in provisions for known integration schemas, provided there was not a deviation from the recommended schema name during the original implementation of the integration. If there was, there’s a way to address that prior to running the scan. There’s also a way to include known custom schemas. When running the scan, be prepared for the process to take a few hours; there are a lot of objects being evaluated.

So, what does Ellucian do with this information? And why do you need to run this? As you’re beginning your migration project, Ellucian, and/or your implementation partner, will use this information to document the current state of your environment. Identifying how far you’ve drifted from baseline will help determine how long it will take to bring things back in line and what baseline functionality might be used to replace long-term customizations.

Do not underestimate this task or sweep this under the carpet. We often forget that we created things many years ago to address holes in the system. However, we rarely go back to evaluate if those holes have been closed so we can deprecate our changes. There’ve been many enhancements over the years and if you can honestly say you’ve reviewed all your customizations every time a new enhancement is released to see if your modification is no longer needed, you’ll be that much further along in this process.

Now that you’ve run these utilities, you look at the output, and it all can seem a bit daunting. Don’t crawl back under your desk. It’s time to organize.

What does this all mean? The analysis of the output will take some time to digest and cannot be done overnight or by one person. The review process will need to be shared by all departments who requested and/or use the customization. This cannot be isolated to the IT department. Regular review meetings will need to be held until all items are identified and classified.

After the shock wears off and you identify how many customizations you have, you’ll want to prioritize them. Separate them into three categories: don’t use, investigate, and must keep. As you prioritize, consider these questions:

  • Are they still being used?
  • When was the last time the job was run?
  • Anything that’s not being used anymore, get rid of.
  • Are those deprecated jobs tied to custom objects in the database?
  • Can those be removed as well?
  • When was the last time data was added to those custom tables? 5, 10, 20 years ago?
  • Do you need to archive it or just drop it?
  • If you archive it, where are you going to keep it?

Bottom line: you’re not alone. Everyone is doing this. Ask questions. Reach out for help. There are people around that can help you organize, identify, and modernize. Don’t think you need to do this AND your daily tasks all by yourself. Remember, it’s not a matter of “if” you’ll move to SaaS, but “when.” As you review your list, consider what can be modified to use some of the newer technologies. You would be surprised at what can be changed now to prevent development delays later.

Anyone who’s said you can’t create or modify objects in the Ellucian SaaS ecosystem hasn’t been keeping themselves up to date on all the features and capabilities available. While the main part of the ERP is locked down, there are ways to extend the functionality of the environment. This is where reimagining comes into play.

Anything on your list of customizations can probably be re-imagined with the new modernization tools. Insights allows you the ability to create custom tables, views, functions, and models for reporting purposes. Schema Designer allows you to extend baseline tables or create custom tables with each automatically generating the applicable REST APIs. Data Connect allows you to update ERP data via the APIs, typically useful when working with integrations. Intelligent Processes coupled with custom Forms and tables can take a constituent through a series of workflow steps that are mostly manual today.

Many people have said, “We are only limited by our imagination.” I completely believe that. However, the willingness to try must follow. Part of the enjoyment I’ve gotten out of learning the new tools is just seeing what they can do and wondering about all the possibilities they can unlock. The more we work with the tools, the more we’ll push their limits, demand more from them, and advocate for the vendor to support them. Isn’t that what we’ve all been doing for the last 20 years anyway? Why should now be any different? Keep pushing forward.

Speaking of what to take with you, in my next article I’ll talk about ERP security and how that will look in the new environment. I will look at what could be cleaned up ahead of time, what will be new, and what will be different. See you next time. Until then, stop hiding and start cleaning. And if you need any help with your work, feel free to reach out to us at SIG.

Ellucian Documentation References:

Written by: Marianne Gillfillan