AEFIS Technology Architecture

A Letter from our Chief Technology Officer

Dear Colleague,

Here at AEFIS, our mission is to create meaningful value from assessment of teaching and learning to enhance student and faculty experience. Our passion for empowering higher education and its students with evidence of learning using your existing accreditation and continuous improvement processes is deeply ingrained in our partnership with you.

The AEFIS Technology Architecture document aims to give you a blueprint of the AEFIS architecture, key architectural elements of AEFIS and an understanding of how AEFIS works with your institutional infrastructure, existing processes, technology and your overarching needs. AEFIS provides you with access to data in ways that institutions may have not had the opportunity to experience in one place, one platform. We hope this document will provide the technology architecture, implementation methods, integrations, software lifecycle, security and performance considerations, related to AEFIS, all in one document, for all stakeholders who are part of your technology team.

We are only as successful as the partners we serve and to that end, we believe institutions have a unique opportunity and responsibility in defining and improving the effectiveness of higher education. Thus, we are committed to providing partners with the most efficient ways to set up and use AEFIS, so that your institutional stakeholders can make the best decisions aligned to institutional strategic initiatives.  By combining our mutual mission and passion to provide a greater value to your institution, we are confident we can assist in moving ever closer to meeting outcomes for student success and institutional effectiveness.

Please feel free to reach out to my team or me personally regarding questions, requests, and concerns regarding this documentation. I can be reached at [email protected] or 877-674-3122 x 2036.

I look forward to building a great partnership with you!

Best regards,

Ozgur Yogurtcu
Chief Technology Officer, AEFIS

AEFIS Architecture

Overview

AEFIS is provided as a SaaS solution hosted in a private cloud instance only accessible by your institution. AEFIS uses a microservices architecture, and a single-tenant DB architecture for institutional data, with separate individual dedicated instances for each client on both application and DB layers. Depending on the service and security requirements of the data (data that’s not institution-specific or not classified as private), some of the services use multi-tenant DB partitions. This model provides a good balance, in ensuring data security, integrity, and performance while maintaining flexibility and scalability. AEFIS Data Model, effectively ensures users are restricted to only their institutions’ information they are authorized to access at the DB Server level.

All management, configuration, operation, and performance management of the AEFIS SaaS solution is carried out by the AEFIS team and the solution is provided as a service. 

Architecturally, AEFIS uses a ‘microservices’ architecture and makes use of multiple programming frameworks and languages depending on the type of the specific service and related requirements. Primary frameworks, technologies, and languages used in the implementation of AEFIS Application Services are:

• JVM Based Application Servers
• Python Data Processing and Workflows
• Purpose Specific Servers and Microservices
• Message Queue / Event Bus Services
• Containerization
• PostgreSQL Database Servers

Implementation Architecture

AEFIS was designed to integrate with your institutional systems to provide powerful features, ease of use, and flexibility for users. During implementation, AEFIS integrates with your institutions three key systems:

1. Single Sign-on / Authentication System
   AEFIS uses your institution’s user authentication system to authenticate users.

2. Student Information System
   AEFIS uses your institutional SIS as the source of truth for institutional data.

3. Learning Management System
   AEFIS uses information received from LMS systems for purposes of assessment and evidence collection. 

Figure 1. AEFIS Network and Implementation Diagram

AEFIS SaaS network design uses the best practices in terms of security. The network separates the external perimeter network from the internal network using a DMZ. All sensitive data is stored within the security perimeter of the secure internal network. Firewalls create a granular control of access between both the external network and DMZ along with the DMZ and the internal network. Host-based intrusion detection systems are utilized in the internal network to trace any malicious intrusion attempt. 

AEFIS ensures data transmitted through any communication channel is secured all the time during transmission. Data transmission between boundaries of the networks occurs during three distinct processes. Below are the overview of these processes and methods used for data security:

1. Transfer of SIS data from the institution to AEFIS: Depending on the configuration of the implementation, this transmission uses either an SFTP or FTPS transport (optionally with PKI authentication) between the institution and AEFIS FTP servers, or an HTTPS transport if an API based endpoint is used on the institution side. 

2. The transfer of data between the AEFIS application and the end-user: The end users access the software and data using a web browser (Chrome, Firefox, Edge or other supported browsers). Data traffic and transfer between the AEFIS server and browser are carried out through HTTPS traffic using SSL certificates. 

3. Transfer of backup data to AEFIS remote data center: AEFIS transfers institutional backups to a secondary location for business continuity and disaster recovery purposes. This transfer also uses HTTPS for security.

Application Architecture 

AEFIS uses the microservice architectural style: building applications as suites of services. This style makes each service independently maintainable, deployable, and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages.

Figure 2. AEFIS Logical Application Services Diagram

AEFIS Application Services are broken down into reasonably sized functional groups that handle a specific set of use cases. Each microservice might be providing a horizontal functionality used by multiple business functions, such as Workflow or Reporting Services, or they might be implementing a specific business function, such as Faculty Portfolio or Self Study microservice.

Services such as Monitoring, Asynch Messaging, or Data Workflow Management are higher-level services that provide infrastructure services to all other microservices.

Technical Implementation

Overview

AEFIS strongly believes in interoperability and plays nicely with other systems on your campus.

As described above, in Implementation Architecture, AEFIS is configured to work in integration with your SSO, SIS and LMS systems during implementation.

Figure 3. AEFIS Implementation Data Flows

SSO/Authentication System Integration

Our team will work with you to set up one of the two types of Single Sign On (SSO) authentication integrations we offer. We can integrate using SAML via Shibboleth SP to SAML providers such as Shibboleth IdP, Office 365, OneLogin, and the like. Also, we are a member of the InCommon Federation. The other authentication integration available to you is CAS.

SIS Integration

AEFIS receives data from your Student Information System (SiS) and other key campus systems according to the AEFIS Data Integration Specification. AEFIS Data Connector is the AEFIS System component that integrates with the institutional SIS systems.

AEFIS Data Connector (ADC)

AEFIS Data Connector (ADC) supports multiple methods to receive that data from remote campus systems, including Student Information System (SiS). Transfer methods supported are:

1. Secured Batch File Transfer via SFTP
2. Rest API Calls
3. Web Services Calls

In our past implementations, we have used all these methods successfully. Typically, the method of implementation is decided during the Technical Implementation project planning process through discussions with your technical team. Data is typically sent or pulled every night and automatically uploaded into AEFIS. The most common transfer method is Secured Batch Transfer via SFTP.

Data Feeds

AEFIS uses the following categories of data depending on your onboarding plan and academic needs:

• Organizational Hierarchy and Structure Information
• Course Information
• Course Section Information
• Staff Information
• Faculty Information
• Student Information
• Registration Information
• Program and Degree Information
• Student Degree Information

AEFIS Data Feed Specifications

The AEFIS Team will go over the AEFIS Data Specifications with you at the beginning of your Technical Implementation. Please refer to the “AEFIS Data Integration Specification Document” for details.

LMS Integration

AEFIS seamlessly integrates with Canvas, Blackboard, Brightspace, and other modern LMSs through Learning Tools Interoperability (LTI) and API. Your AEFIS instance can support multiple LMS integrations simultaneously. Based on which LMS that your campus uses our team will provide the proper documentation to complete the integration with AEFIS. Some examples are provided below for reference:

• Canvas Setup
• Blackboard
• Brightspace by D2L
• Moodle

Email Service

AEFIS sends various email notifications to students, faculty, and administrators concerning actions they need to take in the various solutions of AEFIS.  We will work with you to decide if it is best for us to send the notifications via AEFIS email servers or to send them via email servers on your campus.

AEFIS Architecture Key Elements

Integrated Academic Business Domain

AEFIS collects your academic data from your source of truth (such as your SIS or other similar systems) and provides a repository for all of your academic business objects creating an academic platform to manage your institutional processes. AEFIS business objects provide you a complete and integrated platform and provide you flexible and configurable tools to automate your business processes. All AEFIS Business Objects provide:

• Repositories with granular access permissions.
• Data collection and workflows.
• Tagging, attaching documents, notes, or action items.
• Version management.

and other horizontal capabilities that make AEFIS a comprehensive platform for educational impact.

Hierarchical Permission Based on Academic Structure

The AEFIS Platform supports a flexible, hierarchical, role-based, authentication and authorization framework where users are granted access to specific business functionality and data based on their role in the organization hierarchy. The definition of access in terms of both data and business functionality is extremely granular. A user might be given access to a single business operation ( i.e. Course Finalization operation) while the user might be denied access to edit any attributes of the course. This access may be limited to a single Course, a group of Courses, all courses within a Department, or any similar grouping. The AEFIS Platform has a flexible permissions architecture that allows granular modification or pre-set user security roles. AEFIS supports permission units and access levels based on the organization hierarchy and existing units of your institution.

Business Object Workflows and Artifacts

AEFIS Business Objects are the core functional objects that create the base of the institutional business logic in AEFIS Platform. All AEFIS Business Objects support a similar set of horizontal functionality along with their core business logic. This functionality also might differ depending on the group that the business objects is in. Here are some examples of such horizontal functionality that is also reflected in the UI.

• All business objects support the same structure of hierarchical permission based on academic structure as described in the section above.
• All objects can be tagged by keywords or other business objects.
• It’s possible to attach notes, action items, or documents to all business objects.
• All business objects support an internal workflow of creation/publishing.
• All but some of the business objects support versioning and change management.

Dynamic Form and Workflow Design

AEFIS Platform uses a template-driven approach to data management and is completely customizable in terms of collecting data whether it’s for surveys or data related to any business object in the system. The platform supports the end-user customization of all templates that drive its business objects, including portfolio layouts. Templates for self-study and program assessment enable users to design forms that include multiple question types depending on the type of template they are creating. In that sense, AEFIS form templates can support smart form items, which means the form item is aware of the business object that data is being collected on and can act accordingly. This makes AEFIS data collection forms very powerful, as it gives us the ability to show CLOs in a course when collecting data related to courses or show assessment results in a course section and receive feedback, all through completely dynamic user-designed form templates.

Figure 4. An AEFIS Workflow View

Version Control and Change Management

AEFIS supports version control and change management for all business objects and templates, and historical changes can be easily tracked and reported longitudinally. Thus as your institution improves your curriculum all past versions of your courses or programs are recorded. Similarly, your syllabus which is a flexible designed data collection template also records and preserves all past versions and changes.

Event-Driven Architecture

AEFIS uses event-driven architecture, to orchestrate important business functions like starting surveys, activating sections at the beginning of terms, etc. The event-driven architecture enables synchronization of complex business events and enables flexible scheduling. Any business action in AEFIS such as a student receiving an assessment, a term starting, or a form submission, creates a business event. AEFIS can be configured to trigger specific actions based on business events that occur in the system. For this use case, AEFIS will be configured to create a new data collection form (a survey form) based on a student’s enrollment status change business action.

Figure 5. AEFIS Event-Driven Architecture

Scheduling and Automation with Academic Timelines

AEFIS Platform aims to provide a set-and-forget type of implementation for all your institutional processes. Thus AEFIS highly makes use of scheduling configurations and automation of scheduled processes. AEFIS uses your academic concepts and timelines, in terms of scheduling and provides complete flexibility while identifying the schedules, patterns and deadlines for your institutional processes.

AEFIS Scheduling uses concepts like terms, academic years and ability to set milestones around them using your institution’s timelines. You can use Term Start or End Dates, flexible milestones as Last Day of Class, First day of Finals etc. Moreover you can identify offsets based on these days. With day or week based offset from those milestones, you can configure any type of schedule only once. AEFIS Event-Driven Architecture, will correctly send notifications related to your process, start your process, send reminders as long as your process is going on and finalize the process and send the results all based on your predefined academic calendar based timelines.

Hierarchical Settings and Customization

AEFIS platform is highly templates and settings driven. The templates and settings follow the complex academic hierarchy and can be set at institution, college, department, program, course, or other similar academic business object level. AEFIS platform settings are customizable using the AEFIS UI and create a flexibility to adjust the behavior of specific functions and processes at different levels within your organization.

AEFIS hierarchical settings can be set at a higher level, when set at a higher level they’ll be inherited at all lower levels, yet they can also be customized in any of the lower levels, providing your institution a way to identify your institutional defaults but also a chance to change and customize the behavior at any individual level. AEFIS hierarchical settings also provide a way to govern and enforce specific behaviors. Any setting can be locked at any level, and when locked can not be i[dated at a lower level. Thus if necessary, your organization can enforce a specific process or form at any level.

AEFIS Integration Methods

AEFIS provides multiple methods for application and data integration with other institutional systems. Your institutions can use all these different methods for integration depending on your use case.

AEFIS API

AEFIS Application Programming Interface (API) provides access to your AEFIS data for use externally in other applications, for data access, data consumption, reporting, or any other application integration purpose. 

Access to the AEFIS API is secured using a hierarchical permission structure similar to that of the AEFIS Platform. 

AEFIS DW Interface

AEFIS Data Warehouse Interface (“DW Interface”) provides access to the flat and analytics-ready version of your AEFIS data to import into your data warehouse. Once AEFIS DW Interface is implemented, you can use AEFIS data in your institutional reports or dashboards. All AEFIS Analytical data is available through the DW Interface.

AEFIS Event Subscription

AEFIS uses event-driven architecture, to orchestrate important business functions like starting surveys, activating sections at the beginning of terms, etc. The event-driven architecture enables synchronization of complex business events and enables flexible scheduling. Any business action in AEFIS such as a student receiving an assessment, a term starting, or a form submission, creates a business event. AEFIS Event Subscription provides an endpoint for our partners to subscribe to specific business events and get notified when such an event occurs.

Software Development Life Cycle

Monthly Release Process

AEFIS has a monthly software release cycle. As a modern EdTech company, we are very proud of the effectiveness of our short SDLC cycle. We believe monthly releases ensure that support requests and feature improvements are completed quicker also ensuring the proper amount of development and QA. Each monthly release has an overall goal as well as a list of client requests and feature improvements that follows the AEFIS Product Roadmap.  

On the first Monday of each month, the latest release becomes available on your institution’s Training Sites. Our normal process updates your production system within the next month based on a predefined schedule. For any reason you might request to delay the release for 3 months. Client sites that are more than three (3) release versions behind are required to update.

AEFIS has an automated SDLC which ensures traceability from the creation of the ticket to deployment. We also heavily use DevOps to minimize the possibility of human error in this process. Here is the outline of the mentioned process:

• Any code change is tied to a ticket, whether it’s a bug fix, improvement, or a new feature.
• We use Feature Branch Workflow for any change in the codebase.
• Each code change that was made in the related feature branch is merged through a pull request.
• Each code change is reviewed by key team members in terms of code quality and security and merged to the main branch or related version branches.
• AEFIS Continuous Delivery process ensures the build and deployment of each change into the test environment where each new feature or bug fix is tested.
• AEFIS Continuous Delivery tools are further used for the creation of each release and deployment of the release to the right customer environments once the related change management procedures are completed. 
• AEFIS releases a new version of AEFIS software every month. Every week, customer sites can receive a new version (major deployment) or update to an existing version (minor deployment). 
• Any change on Major and Minor Deployments are discussed in weekly AEFIS Team Meetings.
• Each major version update is also being discussed in monthly Product Deployment Review Meetings in terms of both QA and technical implementation.
• Once submitted, the change will be deployed to the AEFIS Staging systems. Any pull request from the Development Team must be merged before the AEFIS Team Meeting on Mondays to be released to the production that night.
• Change must pass QA (by the QA Team for Major and Minor Deployments and by the Infrastructure Team for Infrastructure Updates) before the final deployment. The QA Team approves or fails the deployments by 3 PM on Mondays.
• The initial QA implies an integrated release test for the Artifact set to be deployed is carried out in the Staging environment which is a copy of your institution’s production environment.
• If Major and/or Minor Deployments fail in the QA, the CTO should discuss how to proceed with the QA and Client Success Teams.
• All change deployments (non-production or production deployments) must be made only by authorized AEFIS infrastructure team members.
• Change must go through final review after final deployment. The QA and Infrastructure Teams do these reviews together on Monday nights. This review also includes automated smoke testing integrated with the deployment process.
• AEFIS ticketing system will provide appropriate notifications automatically to related parties. All parties are responsible to respond to the notifications promptly.

Service Lifecycle

AEFIS Service Life Cycle identifies the documentation and approval process of software changes before those changes are implemented. This well-defined process makes sure the release process follows AEFIS company strategy and every code developed, moves into production with proper vetting in terms of functionality, quality and security. Major or minor software releases are subject to the Service Life Cycle, which requires acceptance of the Client Success Department and the Product Steering Committee prior to implementation. This life cycle is inherently performed during the planning and rollout of new features for the AEFIS SaaS offering.

AEFIS Service Life Cycle consists of five main phases:

1. Plan,
2. Implement,
3. Test,
4. Release,
5. Maintain.

These phases are applied based on AEFIS SDLC and Change Management Workflows. Please find the details of the Service Life Cycle below.

Figure 6: AEFIS Development Service Lifecycle

Security

AEFIS is committed to data security and protecting all confidential data that we collect, store, process, and transmit. AEFIS Assurance (AA), as a key strategic initiative, oversees a group of governing principles, controls, and policies, that provide security within the AEFIS organization, the AEFIS SaaS platform, and for AEFIS partners.

AEFIS Assurance

AEFIS Assurance is the name of a governing committee at AEFIS, and a group of governing principles, controls, and policies maintained by that committee. AEFIS Assurance manages security-related processes within the AEFIS organization, AEFIS SaaS solution, and for AEFIS partners. AEFIS Assurance authority and responsibilities cover all tenets of security; confidentiality, integrity, availability, and protection of personally identifiable information (PII).

AEFIS recognizes that information security is key to the success of our business. With this overarching principle, we aim to implement best practice security principles in our software development, data management, services, and operations, thereby reducing the risk and minimizing the impact of security incidents, to protect our partners’ data, protect our reputation and support our business growth in line with our strategic goals.

AEFIS Assurance was built upon and is continuously being enhanced based on the AEFIS Assurance Controls Framework, which was created using Adobe’s Open Source Common Controls Framework (CCF) v3.0. Using AEFIS Assurance Controls Framework;

• We deployed a set of critical controls that provide security.
• We identified a prioritization scheme and a deployment plan to increase the number of controls based on a predefined priority.
• We were able to utilize existing mappings that relate AEFIS controls to different compliance and audit standards, minimizing the effort required for external audits and certifications.

AEFIS Assurance Compliance

AEFIS Assurance Compliance Project is the current compliance efforts within AEFIS Assurance with a specific focus on;

• Reviewing and updating existing AEFIS Assurance process and documentation
• SOC 2 Compliance and Audit
• ISO 27001 Compliance and Certification
• HIPAA Compliance

Based on AEFIS Assurance Compliance Project Plan SOC 2 Type 2 compliance will be received by Q2 2021, ISO 27001 by Q3 2021 and HIPAA by Q4 2021.

Key AEFIS Assurance Controls

At this time, we have 210 AEFIS Assurance controls mapped to ISO 27001, SOC 2, FERPA, and HIPPA. Here’s a list of key AEFIS Assurance controls and policies related to important security processes and brief summary of the contents:

Business Impact Analysis

This process is covered by AEFIS Assurance Business Impact Analysis Control and this control is used to define the methodology and process for assessing the impacts of disrupting AEFIS’s activities, and for determining continuity and recovery priorities, objectives and targets.

Using this methodology each system is identified and categorized and each system found to be a critical service based on the impact category were set respective RTO and RPO targets. 

Backup Management

This process is covered by AEFIS Assurance Backup Configuration Control. In this sense, AEFIS performs regular data backups to resume system operations in the event of a system failure. AEFIS performs backup restoration or failover tests regularly to confirm the reliability and integrity of system backups or recovery operations. These backups are securely stored in an alternate location from source data.

Backup Configuration control lists systems related to the services identified in the Business Impact Analysis and identify the backup configuration strategies related to those systems.

This control also outlines the plan around testing the local and remote backups.

Business Continuity

This process is covered by AEFIS Assurance Business Continuity Plan Control and the purpose of this control is to guide the restoration of facilities and critical business processes.  It is essential that AEFIS provides an ongoing supply of its SaaS offering and provides business services at an acceptable level. The BCP defines the recovery procedures required to continue/restore core services in the event of a disaster. This plan describes the organizational framework and procedures to be activated in the event of such disaster, and the relevant business units supporting these services.

To enact the Business Continuity Plan, AEFIS will first evaluate the cause of the disaster and all potential impacts of the disaster’s scenario(s). Once service operations impacted by the disaster are established, which could include loss of data center operations, software, facilities, key personnel, etc. The specified plans will be executed to remediate the situation(s) within the RTO and RPO targets set in the Business Impact Analysis.

For example, in the event of the loss of datacenter operations we would immediately contact our internal response team and kick-off the incident response communications plan. Then within 2 hours establish the extent of the loss and decide if a disaster recovery site move is necessary and begin the recovery process based on loss analysis. Within 4 hours, implement temporary solutions to bring minimal operations back online and have a plan for a fully functional disaster recovery site. Such as if a physical server were to become inoperable, within 4 hours we would have a temporary solution in place. Then within 24 hours we will have sanctioned replacement equipment and have that replacement fully functional within 48 hours.

Risk Management

This process is covered by AEFIS Assurance Risk Assessment Control and the purpose of this control is to define the methodology for assessment and treatment of information risks in AEFIS, and to define the acceptable level of risk according to the international information security standards. AEFIS management performs a risk assessment every 6 months. Results from risk assessment activities are reviewed to prioritize mitigation of identified risks.

Patch Management

This process is covered by AEFIS Assurance Change Management Control. AEFIS Infrastructure Team continuously monitors the patches and upgrades of the software in the AEFIS technology stack. System and software-related updates are carried out at regular intervals with each AEFIS release to customer sites. Such updates follow the normal AEFIS software release process. The software updates and patches are installed initially on the customers Test environment and reviewed by AEFIS for compatibility. If the update works as expected, it’s installed to the customers Staging (Also call training) environment. Once approved by the customer the updates are installed to customer production systems. AEFIS security team also closely monitors security digests and announcements related to the products in AEFIS technology stack. Any vulnerability or risk that could impact AEFIS system software or environment is reviewed and acted upon based on the severity of the incident. In case of a high risk incident that could impact our customers, customers are alerted about the situation and updates are performed outside of standard AEFIS maintenance windows. Regular maintenance windows are: Hardware/Infrastructure maintenance is performed on Sundays from 6AM to 12PM ET. System Software, Application and Data maintenance is performed on Mondays from 8PM to 12AM ET. There will not necessarily be downtime during each and every maintenance window. When downtime during the regular maintenance windows is required, AEFIS notifies the customer one (1) week in advance. In the unlikely event that emergency updates or fixes are needed, these are performed on an as-needed basis if it is determined that the outage cannot be postponed until the next regular maintenance window due to impacted service.

Incident Management

This process is covered by AEFIS Assurance Incident Response Plan Control. AEFIS Assurance has an established Information Security Program and this program defines security related policies including system level security measures, application level security measures, risk assessment, incident response and business continuity. The incident response policy includes processes related to:

• Preparation: Deploy tools and provide training for incident prevention.
• Identification: Identify incidents thoroughly; analyzing all the information related to the incident.
• Containment: Contain the issue immediately and prevent any collateral damage including preventions such as revoking user accounts, blocking access to the servers.
• Eradication: Get rid of the malicious code, unauthorized access, or bad employee that caused the incident.
• Recovery: Make sure the issue is resolved and the system is updated in the right way, before returning it to service. Continue to monitor the system for any similar behaviors to ensure that the incident has been fully resolved.
• Lessons Learned: Put together a report detailing what happened, why it happened, what could have prevented it, and what you’ll be doing to prevent it from happening again. Update relevant policies to ensure the issue will not happen again.

Performance

Performance testing is an important part of our SDLC process for evaluating how AEFIS performs in terms of responsiveness and stability under different workloads. Our tests examine speed, robustness, reliability, and scalability of the system under specific scenarios and different loads. We test, analyze and report “performance” indicators such as:

• Browser, page, and network response times
• Server request processing times
• Acceptable concurrent user volumes
• Processor memory consumption; number and type of errors that might be encountered under load

Figure 6 displays the results of one such analysis using a common AEFIS usage pattern. In this analysis, each thread simulates one real user request to the server. Thus 20 concurrent threads stand for 20 instantaneous users sending requests consecutively without pause. This maps roughly to 200-300 concurrent users using the system. The graph displays the systems’ average response time as the number of threads are increased up to 150 which would mean 1500+ concurrent users on the system. The configuration of the environment used for this performance analysis was:

• 2 Load balanced Application Servers
• 1 Database Server

Figure 7: AEFIS Performance Analysis Average Response Time

This configuration is the minimum configuration we use for any of our institutions. Our current production systems typically use 2 to 4 application servers and one database server per institution. The configuration of our production systems are similar to those that are used in the performance analysis. The application servers are scaled as horizontally and database servers are scaled vertically as necessary.

The results achieved above show that the system used can respond to requests under 500 milliseconds up to 150 threads/1,500 active users.

In regular operations, AEFIS SaaS performance is monitored by real-time user monitoring. We use APDEX for measuring and managing the performance of our service offering. We aim to maintain an Apdex score of 0.85 on average in terms of our user experience. In case our APDEX index falls below 0.80 we scale the overall system for our institution to improve performance of the system.

Logging

AEFIS performs active auditing of all user activities at multiple levels. Every log includes detailed information including the originator, data related to the action, time and other information related to the event. The logs are collected at: 

• UI level: All requests received from users and any response sent to the user is logged.
• Business Function level: Any business action and related data received from the user and the result of the action is logged.
• Exception level: Any error, whether it’s an expected business error, unexpected system error or other failure that arises during normal processing is logged.
• Network level: Any network event is logged with necessary information.

Access to these logs are dependent on the type of the log. UI Level logs are only available to AEFIS team for administrative purposes. Business Function level logs and Exception level logs are available to all AEFIS administrative users with right access rights. Network level logs are only available to the AEFIS network administrators. The logs are maintained between 6 months to 1 year depending on the type of the log.

Standards and Certifications

• IMS Global
  • Comprehensive Learner Record (CLR) v1.0
  • Open Badges v2.0
  • Competencies and Academic Standards Exchange (CASE) Service v1.0
  • LTI Names and Role Provisioning Services 2.0
  • LTI Assignment & Grade Services 2.0
  • Learning Tools Interoperability (LTI) v1.3
  • LTI Advantage
  • Standards First Pledge
• In-Common Federation