The core mission of EDAS is to provide innovative and reliable technologies to ensure efficient operations for students, faculty, and staff. EDAS develops and supports enterprise and departmental processes, applications, and databases to support UA business operations.

Services

1.) Third Party Application Support (ERP [Banner], OIT Enterprise [e.g. Atlassian Cloud, Microsoft 365, Zoom], Department-Owned Enterprise [e.g. Action Card, AIM, DegreeWorks, OnGuard, SARS], Departmental [e.g. ISSM, Mercury, TM1])

1. Support for applications running on SaaS-cloud models, and on-premise Windows Server and Linux (SUSE Linux Enterprise, OpenSUSE Leap, Oracle Linux, and Rocky Linux) operating systems
2. Maintenance of applications and underlying infrastructure
3. Integrations
4. Data reporting
5. Custom development of processes and applications to facilitate additional functionality to review and update data within the application
6. Directly troubleshoot and assist in solving issues related to the application, as well as work with the vendor to find resolutions
7. End-user support is limited to certain applications
8. Work with Functional Business Owners to define other support needs. Functional Business Owners are expected to provide documentation and training to users. Functional owners may also be responsible for a number of administrative tasks pertaining to the application/system.

2.) Custom Development of Applications, Processes, and Workflows (Using Laravel PHP, .NET, Oracle APEX, Power Platform [Power Apps, Automate, Virtual Agents], DocuSign, FormFusion, K2, OnBase, UIPath)

1. Review business processes, determine requirements, and develop processes to meet your needs
2. Initial training and documentation
3. Continued support of the developed process or application
   • Maintenance of the underlying infrastructure to ensure the solution continues to function properly and securely
   • Enhance solutions with additional modifications, features, and improvements
   • Data reporting
   • Troubleshoot to solve issues related to the application

3.) Single Sign-On Integrations

1. Configuration of SSO to outside applications with the University’s Identity and Access Management systems, including CAS, Shibboleth (for InCommon Partners), and Azure AD, using CAS and SAML protocols
2. Management of CAS login screen
3. Management of MFA integration
4. Maintenance of SSO tools and their underlying infrastructure
5. Troubleshoot and assist in solving issues related to the application
6. May require approval from OIT Security and/or Data Steward depending on needed data elements

4.) Microsoft 365 Support

1. OIT provides support for all Microsoft 365 products that UA offers, while EDAS provides a subset of services, including:
   • Power Platform and Microsoft Fabric development and consultation
     • Support for various Power Platform and related tools, including Power Apps, Power BI, Power Automate, Power Virtual Agents, Data Gateway, Data Factory, OneLake, Dataverse
   • SharePoint consultation and initial setup and configuration
   • Migration of shared drive content to SharePoint or OneDrive
   • Teams add-on and feature management
   • Directly troubleshoot and assist in solving issues related to the above items, as well as work with the vendor to find resolutions

5.) WordPress Support

1. Direct support is limited to certain websites
2. Strategic Communications can provide WordPress themes and support. Reach out to their Web Strategy director, Kyle Fondren, kyle.fondren@ua.edu for assistance
3. The domain name must be approved by Strategic Communications via https://stratcomm.ua.edu/web-strategy/url-assignment/
4. OIT can provide hosting of the website by contacting the IT Service Desk at itsd@ua.edu

6.) Reporting + Reporting & Analytics Infrastructure Support (Using ARGOS, Axiom, Crystal Reports, ePrint, Tableau, Power BI, Microsoft Fabric [Data Factory, OneLake], Dataverse)

1. Provide tools so that departments and customers can create and manage their own data sources, reports, and dashboards
2. Assist in building and maintaining data sources, connections to data sources, and ETL processes
3. Maintenance of these tools and their underlying infrastructure
4. Directly troubleshoot and assist in solving issues related to the tools, as well as work with the vendor to find resolutions
5. Direct support of writing reports in certain circumstances

7.) Database + Database Infrastructure Support (Oracle, SQL Server)

1. Support for Oracle and SQL Server database management systems
   • OIT can provide a MySQL server by contacting the IT Service Desk at itsd@ua.edu
2. Direct support of databases and database servers for applications EDAS is supporting
   • Additional support models when EDAS does not support the underlying application
3. EDAS can give appropriate users access to the database to manage the tables, procedures, etc. via an IDE of their choosing, such as SQL*Plus or SSMS
4. Maintenance of the database servers and their underlying infrastructure
5. Manage database backups, restores, and data refreshes
6. Monitor performance and take action when necessary
7. Directly troubleshoot and assist in solving issues related to the database server, as well as work with the vendor to find resolutions
8. See item #11 in the Policies and Procedures section for more details on database support

8.) Application Development Infrastructure (APEX, PageBuilder, Power Apps)

1. Provide tools so that departments and customers can create and manage their own applications
2. Maintenance of these tools and their underlying infrastructure
3. Directly troubleshoot and assist in solving issues related to the tools, as well as work with the vendor to find resolutions

9.) Workflow Development Infrastructure (DocuSign, Power Automate)

1. Provide tools so that departments and customers can create and manage their own workflows
2. Maintenance of these tools and their underlying infrastructure
3. Directly troubleshoot and assist in solving issues related to the tools, as well as work with the vendor to find resolutions
4. DocuSign is licensed for faculty/staff use only. Graduate students needing a document signature for class or research purposes will need a faculty sponsor.

10.) Ticketing Infrastructure (JIRA, KBOX, PCR360)

1. Provide tools so that departments and customers can manage their own ticketing systems
2. Creation and configuration of department ticketing structure
3. Maintenance of these tools and their underlying infrastructure
4. Directly troubleshoot and assist in solving issues related to the tools, as well as work with the vendor to find resolutions

11.) GitHub Infrastructure

1. Provide tools so that departments and customers can create and manage their own GitHub repositories
2. Creation of organizations and administrators
3. Enforcement of enterprise policies
4. Maintenance of these tools and their underlying infrastructure
5. Directly troubleshoot and assist in solving issues related to the tools, as well as work with the vendor to find resolutions

12.) Consultant in Residence (CIR) position for Departmental Support

1. A technical employee whose position is funded by and works full-time directly with the department, but is supervised by an EDAS director, has access to EDAS and OIT resources, and is expected to maintain EDAS professional and technical standards and policies.
2. This position will be embedded in the department and take assignments and tasks from a manager within the department, but EDAS/OIT staff may assist in prioritizing and documenting projects and tasks.
3. Additionally, there may be a separate option to partially fund a position within EDAS to assist in supporting a particular department or application.

Policies and Procedures

1.) Any application or process EDAS develops or supports must have a defined data and/or business/process owner. This is the sole person(s) who can make decisions on changes to the application or give permission to others for data access.

1. If a change to a data or business owner is needed, an email must be sent to the EDAS Executive Director or EDAS Director, who supports the process to formally announce the change.
2. Requests for changes to an application or process must be evaluated and approved by the business owner prior to being reviewed and worked on by EDAS.

2.) EDAS is not the data owner for a vast majority of the applications and databases we support, including the ERP. Therefore, EDAS cannot approve data access requests, create or supply data reports, or create integrations between systems without the approval of the appropriate data owner(s).

1. The initial requestor will need to work with the data owner to gain approval and have the data owner submit a ticket with EDAS to do the work unless the data owner is willing to complete the work themselves. The data owner reserves the right to require additional documentation or agreements be completed prior to approving a request and has the right to make a final approval of the finished product prior to go-live.

3.) EDAS is not the business owner for a vast majority of the applications we support. Therefore, EDAS will not be responsible for managing user access within applications, as we do not know what prerequisite training or other requirements may exist prior to granting access, nor can we act as the primary functional administrator for the system.

1. New user access requests need to be completed by the business owner or delegate, or the user request would need to be submitted and approved by the business owner prior to EDAS making a change.

4.) Considerations for Accepting New Requests – When a request is made for EDAS to support or develop a new application, process, database, or department, the following items are taken into consideration:

1. Due to the size of the campus, the number of items we currently support, and our limited resources, EDAS must prioritize all incoming work requests. Change requests for applications/processes EDAS already supports are more likely to be worked on first, especially if it is to fix a bug or defect. New requests must be prioritized based on need, impact, desired go-live date, and resource availability.
   • The requestor must showcase the business need and customer impact.
   • EDAS reserves the right to deny a project based on resource availability.
2. EDAS does not charge for their services in the traditional sense, and thus, we need to prioritize requests from departments that have minimal or no budget or technical resources, and we must prioritize projects related to current EDAS-supported applications where departments are funding the position. Therefore:
   • We may deny a request if it is made by a revenue-generating department, or a department with an existing IT staff, who could otherwise support the request.
   • If a department is requesting support for an application that would require consistent, dedicated time and resources, then the department may have to fund a position within EDAS prior to EDAS taking on support.
3. Per policies 2.0 and 3.0, any request submitted by an unauthorized user without proper approvals may be closed without any work being completed. These work requests need to be submitted by or approved by the appropriate data or business owner, and EDAS cannot work on them until approval is given.
   • Similarly, any request for custom development that would require data from another system would need to have that approved by the appropriate data steward before any work could be done, and if they do not approve, then EDAS cannot take on the project.
4. EDAS will not develop or support an application where the primary users are not UA students or employees, or the purpose of the application does not support the needs of UA students and employees.
5. If custom development is requested, but there is a comparable feature in a currently supported product, or there is a third-party application that provides similar functionality that can be purchased and implemented, then EDAS may deny the request and recommend that the software be purchased, at which point an additional discussion will need to take place to determine if EDAS can assist with implementation and/or support.
6. Prior to accepting a request, EDAS must review the request for technical feasibility. If the implementation requires a framework EDAS does not support or have the technical expertise to support, goes outside the scope of EDAS services, or does not meet the security standards necessary as deemed by the OIT Security team, then EDAS may deny the request.
7. EDAS will continue to support applications/processes we are currently supporting, regardless of any of the above policies, and reserves the right to make exceptions when necessary.

5.) General Work Request Process – Work tasks for EDAS must be properly audited by our ticketing system, to assist with tracking and prioritizing incoming requests, ensuring requests are coming from authorized users (data/business owners), and ensuring they are completed in a timely manner. We also utilize the ticketing system for required auditing purposes to ensure changes are properly requested and approved from development through production, in addition to using the tickets as a form of documentation to track solutions to issues and new feature development.

1. Therefore, all requests for development, support, code or application customization, or data changes must be submitted as a ticket or project request, and reviewed by EDAS prior to any work being done.
   • Any initial discussions through emails or meetings are fine, but for EDAS to begin work, a ticket must be submitted, and details signed off on before any work is done.
   • A department can work with Finance and Operations’ Process Improvement team to help define and outline their ideal business process; details at https://bapi.ua.edu/home-page/process-improvement/; however, if they want EDAS to assist in implementing any new process or changes to an existing process, a ticket with EDAS is still required.
2. The act of submitting a ticket does not mean that EDAS agrees to complete the work or by the initial due date given by the requestor.
   • EDAS must review the ticket according to policy 4.0 to determine its feasibility first.
   • Additionally, EDAS will need to prioritize the ticket against other work and determine a feasible timeline and work with the requestor to establish an agreed-upon go-live date.
3. EDAS will determine how best to implement a solution, and determine the tools/framework that will be utilized.
4. Requirements need to be defined and agreed upon before starting work. If any additional features or requirement changes are later requested during the implementation, EDAS reserves the right to push them to a new ticket or project which will be scheduled and prioritized separately, or negotiate a revised go-live date.
5. Customers must agree to timelines for testing and complete testing by a defined date, and if not, EDAS cannot guarantee the go-live date and may have to push back the date. Customers should not submit a ticket with a due date that does not give them the necessary time to test.
   • If a customer does not properly test or complete testing by the defined schedule, and later discovers issues in the process, EDAS cannot guarantee an expedited resolution.

6.) Ticket Types

1. General Help or Inquiry Ticket – for general questions or if you are receiving an error in an application or unable to login, etc, you can send an email to itsd@ua.edu or go to https://bama.atlassian.net/servicedesk/customer/portal/1. A ticket will be created and triaged by the IT Service Desk, who will assign it to the appropriate OIT resource.
2. Standard Request Ticket –
   • If you are a data or business/process owner of an EDAS-supported application or process, you should have access to JIRA to create a ticket directly in the system via https://bama.atlassian.net/jira. You can also utilize JIRA to review and manage your tickets.
   • If you are not a data or business/process owner, but would like to request single sign-on, DocuSign, Digital Signage, OnBase, or GitHub services you can send an email to itsd@ua.edu or go to https://bama.atlassian.net/servicedesk/customer/portal/1. A ticket will be created and assigned to the appropriate OIT resource.
3. Project Request Ticket – for requesting new support, or the creation of a new custom application or process, a project request would need to be submitted via https://jirauaedu.atlassian.net/servicedesk/customer/portal/22.
   • A project is typically managed by a Project Manager (PM) within OIT’s Project Management Office, and is typically required with any new implementation that will impact numerous departments and stakeholders around campus, will involve numerous teams within EDAS and OIT, or is large and require extended development time.

7.) Standard Request Ticket Workflow

1. The customer will submit a standard request ticket; see procedure 6.2.
2. The appropriate EDAS Director will receive and review the ticket.
   • When appropriate, a standard request will be elevated to the designation of a ‘project,’ which will follow procedure 8.0.
3. The Director will assign the ticket to an appropriate resource to work on
4. The Director or support person may discuss the request with the requestor to determine exact needs and requirements.  
5. The Director or support person will determine feasibility of the requested due date, or if no due date is listed, will determine an acceptable timeline.
6. The assigned resource will begin development in a non-production environment to ensure no disruptions to live systems, when appropriate, and potentially reach out to the requestor as questions arise to ensure the work is done as desired.
7. Once development is completed, the new process will be migrated to an appropriate environment to be tested by the requestor.
8. Once the requestor has tested the process or changes and verifies it is functioning as desired, the EDAS resource will move the change to production.
   • If issues are found, or additional changes are needed, the ticket will be sent back to step 7.6.
9. The requestor is expected to again verify the change in the live production system and sign off on and close the ticket.

8.) Project Request Ticket Workflow

1. The customer will submit a project request ticket; see item 6.3.
2. The project request will first be reviewed by the PMO Director, and a PM will be assigned.
3. The PM will review the project request with EDAS to determine its feasibility and which teams from EDAS may be involved.
4. The PM will schedule a kickoff meeting with the requester and EDAS to further discuss the project details; reviewing the business process, defining the requirements and needs, and determining a feasible timeline for development, testing, and deployment.
   • At either step 8.3 or 8.4, it may be determined that EDAS cannot take on the project either due to available resources or the circumstances of the request as defined in item 4.0, at which point the project will be put on-hold or cancelled.
5. Once the major technical work items are identified, the process will be similar to that of item 7.0.
6. The PM will determine a meeting cadence to keep all stakeholders informed of the progress of the project, work through any roadblocks and action items, and coordinate technical resources.
7. The PM will assist in communicating updates on the project and information about go-live to all stakeholders.

9.) Common Request Types and Processes

1. Request for new support or development:
   • This would require a project request ticket being submitted (see item 6.3) for OIT and EDAS to evaluate the feasibility of taking on this support, evaluated against the previously defined guidelines in item 4.0.
2. Request for a change related to a process, application, or department EDAS is currently supporting:
   • This would require a standard request ticket being submitted (see item 6.2), evaluated against the previously defined guidelines in item 4.0.
3. Request for taking on support of existing, non-EDAS developed applications or processes:
   • This process will mirror that of a new support request in item 9.1.
   • Additionally, these applications need to be properly vetted and reviewed by EDAS staff. Until we can thoroughly review the application and potentially rebuild it in a supported framework, we cannot guarantee or assume full support of the existing build.
4. Process for allowing non-EDAS developers to build applications or workflows in supported tools, such as Oracle APEX, Ellucian Page Builder, Power Apps, and DocuSign:
   • EDAS may provide tools for non-EDAS staff to build their own applications and workflows.EDAS will be responsible for migrating these processes to test and live/production environments, where applicable.
   • The creator must ensure that they have appropriate permissions to view/update the data that is involved in their process. EDAS will not be responsible for inappropriate data access or manipulation.
   • The creator must ensure that the processes have been properly tested.
   • When time and availability permits, EDAS can assist in reviewing the processes and giving feedback prior to deployment.
   • EDAS will not be responsible for, or be held accountable for these processes.
     • If a serious performance or access issue is discovered with a process, EDAS has the right to deactivate the process.
     • If continued issues arise from the same developer or department, EDAS has the right to remove access to the development tools for that group.
   • EDAS will not be responsible for, but can assist with, troubleshooting issues that may arise with the process, when time and availability permits.
   • EDAS will not assume direct support of these processes, including troubleshooting issues or developing enhancements, without properly vetting them, per item #9.3.
5. Process for allowing non-EDAS employees to utilize supported reporting resources and tools, such as Evisions ARGOS, Power BI, and Tableau:
   • This process will mirror that of item 9.4
   • EDAS will make every effort to enable a requestor with the appropriate infrastructure to create, edit, and maintain their own reports. Additionally, in certain circumstances, EDAS can assist with report writing.
     • If EDAS supports both the application and database currently, we can assist in report writing.
       • If the request is not from the data owner, then a discussion will need to occur between the requestor, the data owner, and EDAS prior to any work being done.
         • The data owner must approve of the request.
         • If the data owner has technical resources, they may elect to write the reports and provide them to the requestor in a format of their choosing.
     • If EDAS does not support the application that manages the data that is being requested and the customer/department does not have the ability and/or resources to create reports themselves, the customer will need to submit a request to EDAS, which will follow the process described in item 9.1.
   • Only with the appropriate approvals from the data owners will EDAS create database users and connections for reporting.
   • Reports may need to be restructured based on technical limits of the reporting tool chosen. Some examples include, but are not limited to: max # of rows per page, max size of export, or other processing or technical limitations.
   • Reports may need to be restructured due to size limitations of the intended screen or output the report will be viewed on.
   • Report schedules may need to be revised based on resource loads at certain times.
     • If a report schedule needs to be revised, EDAS will communicate with the report owner to inform them.
     • Modifications to report schedules may not always allow for a time preference.
   • Depending on the reporting tools and data sources utilized, there may be a limitation to how fresh the data is. In some instances, data in reports may be live/real-time data, but in other cases, the data might only be refreshed periodically and could be stale. This is a consideration when evaluating reporting options.

10.) Software Implementation – Ideally, any new software evaluations should be vetted with OIT prior to making a purchase. For any new application implementation, a project request ticket (see item 6.3) should be submitted prior to starting so OIT/EDAS can evaluate, plan, and schedule, so we can best assist with a smooth implementation.

1. We can help to implement software, when applicable, but cannot guarantee complete support of the software in every scenario.
2. If EDAS is needed to implement Single Sign-On, creation of a data feed or integration, or other implementation steps, with no advanced notice, we cannot guarantee we will have the resources available to do so to meet a pre-determined deadline or go-live date.

11.) Database support  

1. EDAS provides database services primarily to assist in managing business operations for the university.
2. EDAS does not support the creation of databases meant for student-use in a UA course.
3. Outside of OIT services, there are free resources a person can utilize to create and manage a database:
   • Some UA colleges and departments may provide technical resources and support, e.g. College of Engineering’s IT department
   • Databases that do not require paid licenses include SQL Server Express, or free Oracle DB or Oracle Database Express Edition
4. To minimize the risk to data security, integrity, and availability, and meet certain auditing requirements, the preference is to limit access to the database server to EDAS DBAs only.
5. Databases will be put on a shared server with other databases, unless circumstances such as the ones below necessitate a standalone server:
   • If anyone other than an EDAS DBA needs to have access to the server
   • If the application needs to run directly on the database server
   • If requirements for security, memory, processors, or storage make hosting the database on a shared server impractical
6. If the requester requires full system admin rights, then EDAS will not support the server or database. The server can be requested from OIT, and EDAS may assist in installing the database software, but will not support the database or server afterwards.
7. If the request entails exceptional hardware specifications; for CPU, RAM, or storage; we may confer with the OIT Systems group to determine technical feasibility or necessary limitations.
8. If the database will contain Personal Identifiable Information (PII) or require special compliance for HIPAA, FERPA, etc, we may confer with OIT Security to evaluate the risk and additional security precautions needed, and determine if OIT can support the request.
9. Database Monitoring
   • For databases with full EDAS support, we will configure alerting mechanisms and monitor for issues related to performance and any database blocks or sessions causing issues.
   • It may be necessary at times to perform stoppage actions for the health of the database or database server without advanced notification. For example:
     • If it is detected that a particular session, user, query, or report is causing issues that are blocking other database processes from running effectively, then that session may be terminated.
       • As the owner of a process, if you are aware you are going to run an intensive process that cannot be interrupted, please provide advanced notification to EDAS.
     • If there are other performance issues that are impacting interdependent systems, we will take action to stop the issue from spreading, including termination of the offending process or shutting down databases and servers.
     • If there is a suspected security breach, the database and/or server may be shut down immediately.
10. Database backup, retention policy
    • For databases with full EDAS support, we will manage a robust backup plan to ensure limited data loss in the event of a disaster, and provide the ability to roll back data changes to a certain extent, if needed.

12.) Upgrade Policies

1. EDAS will regularly apply patches to operating systems and databases, as well as update applications, to keep up-to-date with security patches, latest features, etc. This may require regular application upgrades, infrastructure/software/server upgrades, and associated testing to be completed by the business/data owners and functional users.
2. EDAS will communicate to impacted customers ahead of time, when appropriate.
3. EDAS will work with the business owner to define a schedule for the upgrades, when appropriate.
4. EDAS will maintain backups and create snapshots/backups of systems prior to major work or upgrades, when applicable, so that in the event of issues, we can revert to a stable version.
5. EDAS will perform changes in the development environment first, when appropriate, to ensure any upgrade issues are resolved prior to upgrading the live production system, unless otherwise agreed upon with the appropriate business owner.
6. EDAS will attempt to complete all production upgrades and other work, during the below, defined maintenance windows outside of normal business hours to limit disruption to services, unless approved by the business owner(s). Code migrations may occur during business hours if no or minimal disruption is expected.
   • Saturday: 6am – 12 pm
   • Sunday: 4am – 10am

13.) If EDAS is unable to continue to support an application or process, we will give ample lead time to allow for a transition in support.