Welcome, New Enterprise Developer
12 Dec 2022
Congratulations on joining the Enterprise Application Operations (a.k.a. “Banner”) team in UST ITS!
As its most-recently-hired Enterprise Developer (early 2019), here</span> are a few “lay of the land” tips still fresh in mind that I hope can help you.
Protecting and improving Banner guides our work
We do a lot in this department, and we do it with a lot of technologies, old and new.</p>
Banner is an Enterprise Resource Planning (“ERP”) software suite that includes a few Oracle databases, a lot of web servers that host user interfaces allowing humans to interact with those databases, and a handful of other servers facilitating ad-hoc and scheduled automated/batch workloads.</p>
We didn’t program it – a company called Ellucian did.
We license the rights to download, install, and run their software, as well as updates to it, on servers that we manage.
While it’s the job of talented cloud architects and Linux systems administrators on the Enterprise Application Development & Cloud team to provision and configure these servers (including making sure that ones hosting databases have Oracle installed onto the operating system) with infrastructure-as-code tooling, our team hosts:
- The database administrators (“DBAs”) who configure Oracle database management systems and the databases within them (and occasionally the underlying server operating system environment) to run performantly, be ready for Ellucian products, be backed up appropriately, etc. (Again with infrastructure-as-code / infrastructure-configuration-management-code tooling as best possible.)
- The Ellucian product experts who read all of Ellucian’s release notes and understand what would be required to successfully install any given upgrade from Ellucian into our environments, and who get very hands-on following those instructions during upgrade outage windows (upgrades typically involve both EAO & EACD staff and occasionally even Networking staff).
- (Including at the moment, redeploying containerized stateless web servers after an ERP upgrade. TBD whether that will always be an EAO task, may sometimes be an EADC task, may have people cross-trained from both teams, etc.)
- The PL/SQL and “Extract, Transform, Load” (“ETL”) tool experts who are allowed to use powerful credentials to configure and schedule data integrations and automations into or out of Banner to improve quality of life for various systems’ power users around campus
- Facilitators who write “runbook” sequenced spreadsheets that ensure everyone involved in upgrading the ERP system during a planned maintenance window is able to coordinate smoothly with everyone else.
- Facilitators who help ERP power users remember to keep track of their most common day-to-day operations (e.g. in a centralized QA/testing spreadsheet) and to leverage it and regression-test the ERP thoroughly after nonproduction and production upgrades.
- Facilitators who help ensure that ITS Desktop Support always has a working version of the Appworx Desktop Client in the Windows Software Center and a working vanilla/campuswide version of TNSNAMES.ORA in the Windows Software Center.
- The troubleshooters who take helpdesk tickets observing that something about the ERP doesn’t seem to be working right. (Whether the root cause will turn out to be user error or an actual bug in Banner / its installation onto our servers varies from ticket to ticket – some can be resolved with “see this Knowledge Base article about clearing your browser cache” while others are days of back-and-forth with Enterprise Application Development & Cloud trying to figure out Java Virtual Machine memory leaks, etc. Either way, we support the “the ERP’s broken” tickets.)
While many Banner power-users around campus have access to Ellucian’s Action Line (Ellucian’s tech support center), and are better equipped for formulate questions about issues that arise using particular parts of Banner tailored to their lines of business:
- People on our team all have Ellucian Action Line requests and correspond with Action Line on behalf of other people at St. Thomas when something is not working correctly and no one on campus can figure out why and having an end user open the support ticket really wouldn’t make sense.
While many PL/SQL and DML experts across campus (e.g. SDR, Controller’s, University Advancement) might “throw code over the fence” to this team for ad-hoc execution or escalation into production and scheduling with a tool like Appworx after a brief peer-review by this team:
- Sometimes, this team does original implementation work, starting only with a set of functional requirements as developed by end-users. This is particularly common when a department has purchased a new 3rd-party software-as-a-service (“SaaS”) tool and wants to load it with data from Banner, or feed data back into Banner, over:
- SFTP (typically scheduled with Appworx and invoking a standardized Linux shell script that lives on Appworx’s server),
- An HTTP API (typically scheduled with Appworx and invoking Python scripts that we need to write ourselves and that live on Appworx’s server – thus far, Python is the best scripting language we’ve found that Appworx can invoke for interacting over HTTPS),
- Manual file operations by end users within a departmental Sharepoint folder (typically scheduled with Appworx and invoking a standardized Linux shell script that lives on Appworx’s server),
- Appworx is a great tool both for scheduling code to run against Banner or SFTP or HTTP APIs or Sharepoint drives and for wrapping such code in a “big run button” user interface that power-users in departments can be trained to click as needed ad-hoc.
- This team also ends up involved in many Salesforce ETL initiatives, even if those automations do not need to connect to Banner, because our best ETL tool for connecting to Salesforce (Jitterbit) does not allow us to smoothly “hand over the keys” to developers outside of our department without putting Banner credentials we do not want them to be able to use at risk.
This team also collaborates with Application Development & Cloud to various vendor-authored “middleware” tools that UST installs onto various servers and runs (eProc/eInvoice for Jaggaer purchasing & payables, TouchNet for TouchNet payment processing, AXIOM for ACES Law School applications, eVisions for printing things beautifully from Banner onto paper, TDClient for federal financial aid, etc.).
Note that this team does not do a lot of SQL or Cognos query writing for consumption by end-users – that is IDAR’s domain. While this team is full of expert query writers, they mostly do so to support efforts that write data into Banner, or efforts that read data out of Banner so as to write it to another system.
Drinking from a firehose
Everyone on the team is really good at different things. We all have PL/SQL as our bread and butter (but we’re varying degrees of good at it), but don’t be intimidated that you only understand, like, 2 of the 20 technology stacks we’ve cobbled together into productivity improvements for the university. You’ll learn the other 18 eventually as you help out. It’s unrivaled on-the-job professional development.
Speaking of making sense out of a world that’s “cobbled together” – please talk to IDAR about best practices for documenting every integration you create or edit inside of the “Data Cookbook” governance tool they maintain. Also please talk to Client Services about best practices for the ITS Knowledge Base documentation site. Being an active contributor to these two tools is a very quick way to make new BEST FRIENDS at St. Thomas.
We’re not using-Banner experts, as funny as that sounds
This team has a quirky relationship to “how Banner works”: we learn a lot about it by being here for decades and helping various business users who come and go with one ETL project or Action Line ticket at a time.
However, we’re not expected to be very good at being a Banner end-user.
We might be! We’ve been here a long time and learned a lot!
But we’re not performance-reviewed on our intimate knowledge of the correct way to enter an admissions application into Banner tables dedicated to tracking such things, for example.
That’s supposed to be professional development that departments send their power users to the Upper Midwest Banner User Group to learn, that they have their power users read support documents within Ellucian’s Action Line support center to learn, that they cross-train within their departments on, etc.
When in doubt, “I don’t know; let’s see if we can figure this out together” is a great attitude.
Check in with the Enterprise Application Operations director and other colleagues for history to get a sense of how much of a business problem at hand might be “department’s cross-training fell apart and needs a booster shot to be revived, and then they can take it from there” vs. “this is actually a tricky problem requiring escalated credentials and coding skills that’s precisely the reason our team exists.” (Often it’s a little of each, and that’s okay.)
Document lessons learned appropriately / partner with power-user department to help ensure lessons-learned for their side are documented appropriately.
Similarly, if a department needs a brand new ETL job or experiences a Banner failure, it’s very normal for us to say, “I’m sure we can figure this out with you, but I don’t work day-to-day in that part of Banner—can we do a drivealong so I can see what you’re seeing?”
It’s also very normal for departments to have no idea that the “Banner team” doesn’t actually know a lot about their part of Banner and to be confused by this request – patience and customer service skills are a virtue!
Note that although we’re not expected to know exactly which data belongs where in the entirety of Banner, we’re definitely expected to ask excellent questions of the power-users who do know (and/or to partner with them until we all figure it out) and to test test test test test test test test test test.
With great power comes great responsibility. We can write a lot of bad data very quickly with the access we have to Banner and other data systems (via their API keys, SFTP keys, etc.), so it’s our job to “measure twice, cut once” when we collaborate with end-users building or editing ETL, DML, etc.
For PL/SQL experts, we don’t write a lot of stored PL/SQL
We’d rather have 1 anonymous PL/SQL script fail at runtime than have 1 compiled PL/SQL script’s failure to play nicely with an Ellucian-delivered ERP upgrade show-stop the upgrade.
While we’ve written and compiled a few scripts into the database (“ust_global.ust.f_pidm_to_banner_id”, for example – and we also often customize some of the stored procedures that drive certain user interfaces in Murphy Online), most of the PL/SQL code we write to solve business problems is “anonymous PL/SQL” in “.sql” files stored on various servers (we get it there through a Continuous Integration / Continuous Delivery pipeline set up with Git, AWS CodeCommit, and Jenkins), not compiled into our ERP databases.
Sometimes that makes for additional overhead to adapt “PL/SQL” tips & tricks found on coding blogs work in our scripts (since the blog examples are often written with compiled procedures).
Web development
Just how involved we get in HTML and CSS and JavaScript stuff is a bit iffy. We definitely lean heavily upon power users in SDR (Ellucian Page Builder), Enterprise Application Development & Cloud staff (full-custom things like ClassFinder), etc. rather than pretending to be web experts ourselves.
See the KB article Building interactive websites that sync to Banner for an overview of some of the technologies in use.