Content uploaded by M. K. S. Sastry
Author content
All content in this area was uploaded by M. K. S. Sastry on May 19, 2020
Content may be subject to copyright.
110
Copyright © 2020, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Chapter 6
DOI: 10.4018/978-1-5225-9829-9.ch006
ABSTRACT
Modern universities thrive on the information gathered through well-managed information systems. The
overall process of developing and maintaining Academic Information System (AIS) all within the university
and without any external assistance is generally regarded as a mark of achievement. This chapter deals
with various aspects of AIS such as requirements, development, testing, overall security, etc. Two major
options, developing AIS from scratch and deploying a commercially available software solution, are
discussed. Typical management strategies are suggested to combat possible resistance from users and to
serve a wider-ranging user community in an effective manner. A strong case is made in favor of in-house
development of AISs to reduce initial costs and maintenance expenditure. Importantly, the process of
design, developing a functional prototype, and overall security aspects are presented in detail. Several
recommendations are made to deal with various operational challenges through well-known practices.
INTRODUCTION
Effective management of any educational institution requires a lot of information that is properly cap-
tured, processed and managed. Raw data or Information, in various forms comes from various corners
on continuous basis and generally educational institutions use various automated tools to process the
same, besides manual or legacy methods. In the current digital age, university communities heavily
depend on free flow information. Some of the instances include - students need information on possible
course registration options, examination timetables; academic councilors may need to access up-to-date
Management Information
Systems for Higher
Education Institutions:
Challenges and Opportunities
K. S. Sastry Musti
https://orcid.org/0000-0003-4384-7933
Namibia University of Science and Technology, Namibia
111
Management Information Systems for Higher Education Institutions
transcripts; bursary staff may need information on current and past budgetary expenses to determine fee
structures, scholarship funds; managers may need access to payroll for processing salaries etc. Naturally,
there will be wide ranging tasks and requirements for core activities (or business processes) of any typi-
cal higher education institution (HEI). Then, requirements for information vary widely based on the
type of user. It is common to see that HEIs using different software applications for different purposes
and naturally spend a lot of money towards procuring and periodical renewal of licenses. Hence, it is
imperative for the HEIs to rely on information systems and continue to invest in their management to
enable everyone to function properly.
Information Systems for HEIs have been reported widely over the years. There are different layers and
categories in which these information systems operate and thus have different objectives. For instance,
phrases such as Student information systems (SIS) or Academic Information systems (AISs) have been
generally used for information systems that mainly manage student related data in any HEI. In the lit-
erature, phrases such as Education Management Information Systems (EMIS) or simply Management
Information System (MIS) or Information System for Higher Education (ISHE) have been typically used
for integrating information from different universities to bring them to a common operating platform
for analysis or data aggregation purposes. In general, EMIS is smaller layer and works on top of AIS,
which is larger layer. Then EMIS typically integrates different database layers such as AIS, HR, Payroll
and other financial aspects of different HEIs. EMIS typically obtains information from various HEIs.
Figure 1. shows a typical hierarchy of various information systems, one EMIS that works from different
information systems of two different HEIs.
Over the years, various authors have reported on different aspects of information systems, specifically
for HEIs such as – design and development experiences, data quality and management, impact of informa-
tion in decision-making, web portals with academic information etc. Tahvildarzadeh et al. (2017) have
reported various issues with data quality and the need of having an institutional policy on data quality
management. Their study clearly emphasized on having high quality information systems is essential
for university administrators in managing the ever-changing requirements. A few authors (Sastry, 2007;
Soares et al., 2013; Motta, 2010; Zilli, 2014) have presented data models, relationships and Design and
development processes of academic information systems or student information systems which typically
operate at the university level. Indrayani (2013) reported on an information system that was developed
in the city of Bandung, to gather data from 18 different HEIs and to determine various common quality
indicators. In-house development (HEIs developing AIS within their own organization using their own
resources) and successful deployment experience of an information portal in the University of Pretoria,
South Africa was reported many years back (Pienaar, 2003). This portal is meant for assisting research-
ers and professors (and not for serving the wider university communities as moderns AISs would do);
Figure 1. Hierarchy of information systems
112
Management Information Systems for Higher Education Institutions
but the effort itself points to successful attempts to develop applications (and not purchasing an out of
box solution) for internal use.
Success of any EMIS or AIS depends on various factors including its design and operating effec-
tiveness, active user participation, and support from top management (Yaser et al., 2014). There have
been a good number of contributions on this topic from African countries as well where the information
technology penetration is relatively less compared to first world countries. Aldarbesti & Saxena (2014)
reported reasons for failure of EMIS in Nigeria that include lack of interest from stakeholders and federal
governments. Aldarbesti and Saxena (2014) also reported on the major problems faced in the education
system of Zambia that include low literary numbers and lack of teaching and learning resources. Few
other countries in Africa may have similar conditions for obvious reasons. If a government or a fund-
ing agency wants to intervene to solve the existing problems (such as poor academic performance, high
expenditures, lack of transparency etc.) in the education sector, then they require genuine ‘information
and/or feedback’ to determine appropriate plan of action. Even to audit the quality, compare (or bench-
mark) any specific academic program in HEI, lot of information is required. Such exercises obviously
require well-managed AIS.
Duan and Zhang (2007) have reported on designing and development of a MIS to interface teachers,
graduate students and administrators for specific purposes such as analyzing workflow, program manage-
ment, project management, etc. However, designing and deploying such information systems is not an
easy task. Alyoubi and Alyoubi (2013) have reported on experiences from different parts of the world on
information systems implemented successfully and also the challenges faced by stakeholders managing
such systems in HEIs. Their study gathered information from more than 200 selected universities. Their
study found that information theft and loss of privacy are the biggest problems faced by the academic
institutions. Even a few research investigations have been made how best to design information systems
for HEIs and various connected aspects (Luena, 2012; Ommundsen, 2017; Fredrick, 2017, Riswandi,
2017). Quality of information systems is altogether different, but very important. Iman et al (2014)
have studied different variables for quality of information systems and found that users are positively
benefitted. Indrayani (2013) presented a systematic analysis on the outcomes of successful use of AIS
that resulted in overall improvement, management quality in 18 HEIs from Indonesia.
The UNESCO Institute for Statistics (UIS) has been working over the years to encourage various
developing and under-developed countries to undertake digitalization in the education sector. One of
the major initiatives is to help such nations to build EMIS. For this, a taskforce has been setup with the
help of Global Partnership for Education (GPE). It is hoped that through this initiative education sector
can be strengthened and streamlined in participating countries with the information provided EMIS.
This taskforce set a standard ‘SDG-4’ for the information expected, which requires concerted efforts
by various countries in building a robust EMIS. A properly developed and high-quality information
system will provide much required insights into resource utilization, budget allocations and spending,
value of money. In fact, the major challenges SGD-4 are data collection, (and thus) lack of indicators
that are relevant for national planning and implementation of the education policies (Montoya, 2018;
Luena, 2012). Bernbaum and Moses (2011) through an USAID program indicated various challenges
that include capturing hard data, data accuracy and even sustainability issues in managing education
management systems specifically in selected African countries. Luena (2012) and Lupu et al. (2008)
emphasized that stronger and effective information systems can help governments and stakeholders
in proper planning for education system improvements. Even the World Bank’s Human Development
has initiated a project called Systems Approach for Better Education Results (SABER) to support its
113
Management Information Systems for Higher Education Institutions
own Education Strategy 2020 (Abdul-Hamid, 2014). In the recent times, UIS has explained its agenda
on SDG-4 standard of Information Systems in the International conference on education management
Information Systems, during 11-13, April 2018 in Paris, France.
Obviously AIS requires a lot of money and indeed it is financial opportunity for software companies
(Felson, 2015). At the same time, HEIs can save a lot if they develop AIS in-house, for their own use, as
they do employ highly qualified and skilled professionals who can help in the process. From the above,
it is obvious that AISs for HEIs are vital; and this is a well-researched topic; and various international
organizations such as UNESCO are engaging many countries with well-defined goals. One of the big-
gest questions is whether to go for a readymade product (which can be prohibitively expensive) or to
design and develop on own (which has its own challenges). These two options throw different types of
challenges and risks from the initial phases of capturing raw data to processing, and final presentation
of information.
Hence, it can be observed from the literature that Information systems in HEIs
1. Are essential and are very useful in effective planning
2. Are recommended by stakeholders, federal governments even international organizations
3. Have been designed, developed and deployed in many places for different purposes
4. Are complex in nature due varying nature of user requirements
5. Pose several risks (such as loss of data, loss of privacy etc.) and challenges in operation (technical
failures, poor performance etc.) if not designed properly
However, many critical aspects such as operational challenges, cyber security, standards, system
hierarchy/ categorization, changing rules, regulations and their impact on information systems, fac-
tors / reasons that cause failures, overall planning, best practices in managing information systems are
not well presented particularly in the case of educational institutes. Keeping in view of the above, this
chapter deals with overall process of design, development and deployment of a generic AIS for a typical
HEI and treats with most critical aspects and then makes a strong motivation for in-house development.
This chapter is divided into ten sections. Section 2 deals with pros and cons of commercial solu-
tions and in-house development of MEIS. Section 3 explains how requirements are users captured and
then moving how to move forward in terms of making key decisions. Fourth section deals with design
aspects by considering one core business process. Importance of developing a fully functional MEIS is
illustrated in section 5. Security aspects are covered in section 6. Seventh section provides insights into
various operational challenges and makes suitable recommendations. Section 8 deals with best practices
and standards. Section 9 deals with importance of documentation for effective management. Lastly,
section concludes the chapter.
COMMERCIAL, READYMADE SOLUTIONS VS. SYSTEMS DESIGNED IN-HOUSE
A good number of commercial software solutions are available, such as “Banner” developed by Ellucian
Inc; “Rethink SIS” developed by Alma Inc.; “CampusAnywhere” developed by EDC; “student manage-
ment” by Skyward Inc and many more. Though these are undoubtedly popular software solutions for AIS,
there exist several drawbacks. Felson (2015) clearly indicated various problems faced by using popular
software packages particularly in students advising process and even indicated that:
114
Management Information Systems for Higher Education Institutions
The situation is bad enough that students and faculty are taking matters into their own hands. As recently
reported in the New York Times, enterprising students at the University of California–Berkeley, Rut-
gers University, Yale University, and Baruch College have created popular apps that repackage course
schedules provided by their universities into more usable formats.
Obviously, the readymade packages will not be able to address all the needs and even the core
business of a typical HEI, in this case the student advising. This is not a unique or one off experience;
many organizations feel the pinch after using such solutions over a few years and having incurred huge
expenses as well (Vann (2012).
Then, Felson (2015) points to the very important aspect of developing the required solution on
own with an apt title “The Low-Hanging Fruit of Technology in Academia - Is technology in academic
advising a help or a hindrance?” with own success story of developing in-house solution and related
experience which is rewarding. It is interesting to note that the developer is a self-taught designer and
programmer. Karim (2011) has evaluated a good number of student information systems that are devel-
oped at various organizations.
Hence, there are many takeaways exist here:
1. It is possible to develop AIS in-house to meet the requirements of any typical HEI;
2. Many successful experiences of developing and managing AISs are documented;
3. Readymade commercial solutions may not necessarily suit all the requirements, including core
business activities;
4. Core business requirements, underlying technology platforms and operating systems will be chang-
ing on a continuous basis.
On the other hand, software companies that develop and market packages will not be able to design
a solution that works for all the organizations. It is true that companies survive primarily from product
sales, and then add-on modules and customization processes for specific purposes. To be fair, one needs
to understand the costs of human and computing resources, expenses involved in product development,
competition, costs of advertising and marketing etc which naturally push the product costs to a very high
level. Therefore, it is important for HEIs to examine the above aspects to take appropriate decision. Table
1. summarizes the comparative analysis of commercial versus in-house developed software.
It can be seen from Table 1., that the major areas of differences are design, development and test-
ing. Both the approaches pose same challenges in rest of the areas. But really any software application
will have life cycle and must go through various phases as indicated in figure 2. Hence, it is better for
HEIs to develop AIS in-house, on their own. This decision results in creation of a few jobs, building
IT capacity, enhancing quality and service to the stakeholders. Though there will be several challenges
(Vann, 2012), certainly numerous benefits exist in having properly managed AISs. Also designing and
developing AIS on own; and then managing the same over the time is hallmark achievement of any HEI.
Option of Having a Readymade, Commercial Software
Even in the event of a decision favoring the option of having commercial software, then organization
needs to work on a comprehensive management strategy to ensure successful deployment and satisfactory
use of the purchased product. It starts with identification of requirements, changes required in operating
115
Management Information Systems for Higher Education Institutions
processes and core business activities; customization of user interfaces as required; input and output data
processing; information to the stakeholders and data migration (to ensure old records are taken care) etc.
Usually it takes about two or three terms of operation of the product for the organization to get hold on
the usage, provided academic regulations and policies remain constant. In any case, a specialized team
needs to be put in place to manage the overall deployment. It is recommended that the same team be
asked to look into designing and developing better AIS for future use.
Views and Perceptions
One of the most common perceptions is that a readily available commercial software solution is the most
appropriate choice to ensure a smooth transition to an automated system. There are many reasons why
such perceptions prevail. They include – suggestions from an employee who may have work experience
on a specific commercial software, assurances from such individuals or teams to the top management
on managing the software, lack of trained professionals and teams to develop AIS in-house; perceived
risks due to unforeseen failures (or previous experiences of failures) in the development or deployment
process and thus risking the job itself; strong support for ‘standard/ commercial system’ that is specifi-
Table 1. Comparison of commercial and in-house developed software systems
Commercial Software In-house Developed Software
System requirement
specification (SRS)
Actual requirements of the client may not be satisfied
as commercial solutions are developed for ‘broad and
generic requirements’
System requirements can be satisfied as the
solution is made for specific purpose for internal
use.
Design
Design details of the product are not divulged as it is
propriety to the selling company. Design itself cannot
be changed even though requirements of HEIs change
continuously.
HEIs can design AIS as per the needs and
requirements. Design can be altered, but requires
careful planning. Care should be taken to
maintain the confidentiality if necessary.
Development
It is a fully developed solution. Client can customize
or configure as needed. However the internal code
(for further development) is not accessible. However,
the code is very well tested and hence has the highest
quality for delivering what it is supposed to. This is
also one of the chief advantages of any commercial
solution
Internal code is fully accessible and can
be altered as and when required. This is an
advantage and also a disadvantage. Altering the
code without proper care can lead to serious
repercussions.
Testing The product is well tested at various levels. However
further adjustments, configurations need to be tested
Needs to undergo testing almost all the time to
ensure quality and integrity. Usually it takes
time.
Deployment A lot of changes are needed in core activates of the
client organization
No need to change the core processes or
activities
Maintenance Requires periodical maintenance Requires periodical maintenance
Product customization Possible but at higher costs Possible at lower costs and lower turnaround
times
Data archiving and
restoration Needs to be done by HEI Needs to be done by HEI
Data migration to newer
platforms Effort is same as in-house solution Effort is same as commercial solution
Managing the system in
critical conditions
Effort is same as in-house solution, just that client can
pay and get the services of the provider
Effort is same as commercial solution, but
organization has to manage on its own
116
Management Information Systems for Higher Education Institutions
cally designed to meet a particular quality standards; and use of a prescribed software by government or
federal authorities to ensure information flow in a specific pattern across the institutes etc. It is important
to note that previous research clearly indicated that users value the information, if fruitful and timely
decisions (Gurkut & Muesser 2018) can be made. This also means users really do not show interest on
how well the information is presented.
Attempts to develop AIS in-house may fail at various stages due to wide ranging reasons. In such
circumstances, usually top managements may be forced to take a decision to procure some commercial
software in haste. To avoid such circumstances, it is essential to have a well-throughout overall manage-
ment strategy from beginning to end keeping in view of all possibilities. The core readiness is to have a
functional prototype that can deliver most common university processes and yet is very secure. Usually
this alone takes 4 to 5 months of time for an experienced team with careful planning and concerted
efforts. Once the prototype is ready, then overall management strategy needs to be adjusted in order to
undertake full-scale deployment.
Way Forward
From the above discussions, it is evident that managements need to do a thorough analysis for making
a decision in favor or against developing in-house development process. If the decision is to go for in-
house development of AIS, then a systematic management strategy should be devised. After all, it is a
software project, so a standard approach of managing should be though out, that includes a typical life
cycle development model.
Figure 2. A typical software development model
117
Management Information Systems for Higher Education Institutions
Requirements Study
Different stakeholders such as students, teachers, past graduates require different information. Wide
ranging requirements should be properly captured to automate core and internal business processes.
System Requirement Specification (SRS)
SRS is the initial phase and most challenging and critical phase to deal with, especially in university
setting. So, care must be taken to capture all the requirements however exhaustive the needs may be.
For example, if a student needs to fill a form to register in the legacy or manual process, then it is good
to have the user screen replicating the same form/ template to capture information to avoid confusion.
When students see the screen asking the same information, they feel ‘satisfied’ with the new system.
Sections below provide a few examples of users and their requirements in a typical HEI. These require-
ments are only for example and by no means are exhaustive.
Students as Users
Students form the bulk of the user spectrum and thus a lot of care needs to be taken to meet the require-
ments of this user community. Requirements of students as users of AIS include course registration
help on choosing the appropriate courses during registration process, viewing the status of academic
progression, fee structures etc. All such requirements can be automatically incorporated into functional
prototype as they are very obvious. When students attempt to register themselves, the AIS should be
able to present relevant information to each student such as various options for programs, courses and
associated fees etc. At the same time, additional information should be provided on popular courses and
activities. Similarly, any other existing manual process for any purpose should be automated by AIS. For
every transaction, AIS should send an automated email with appropriate details.
Graduated Students as Users
Needs of graduates, as users are different in nature. Accessing student transcripts without much hustle is
the most important requirement. This aspect is not well discussed by previous researchers. Most univer-
sities employ a manual system of money payment and the issue of (physical) transcripts due to lack of
well-defined IT infrastructure and capacity. Online payment process, generation of web links for viewing
transcripts with secure passwords (with limited validity over a time period) are the common ways to
serve graduates. Many universities do have a policy to issue what is called an unofficial transcript to all
registered graduates. Unofficial transcripts can be viewed/ downloaded after logging into the system; and
can be used just as a regular transcript. However, it will have a heading and/or a watermark across stating
that it is only unofficial transcript. Such system is a good way to support students; and also to keep the
past graduates connected to the university systems. Unofficial transcripts can be used by graduates in job
hunting process and to gain admission in high education programs in other universities. Such features
(or abilities) of the information naturally enable the students in moving forward without any hassle and
also make universities look distinctive. Such capabilities can create a general belief and perception in
the student’s mind that they have studied (or studying) in a ‘better or modern or reputed university’.
118
Management Information Systems for Higher Education Institutions
Teachers as Users
Teachers contribute significantly to the data transactions. Activities include verification of course de-
tails, assessment components, pre-requisites, registered students and submission of marks through the
academic term for different assessments. Then, some teachers may have special requests. For example,
teachers handling basic sciences and mathematics may have few hundreds of students in large classes.
One of the most commonly requested feature is to enable marks submission from an excel sheet or even
a simple text editor. Generally, most software applications expect that the teacher enter student number
and marks one by one, which will be very taxing when the class size is big. If AIS can support ‘copy
and paste’ from an excel sheet then teachers will be relieved.
One of the key activities at the beginning of each academic term is course-teacher-student data popu-
lation. This involves teachers (or departments) making the courses ‘live’ so that students can register.
Users will be able to see various courses offered in that term across the university along with the name
of the professor, credit hours, course outlines, pre-requisites and assessment criteria etc. If there are any
discrepancies, naturally flags will be raised by either teachers or students or Heads, etc., and the infor-
mation can be updated as needed. Hence, this is an important activity that essentially starts well before
the start of the academic term and goes through the term, and up to the point of finalization of grades
etc. Figure 3. shows this process.
Officers and Administrators as Users
In any typical HEI several layers and numbers of officers and administrators exist. One of the technical
challenges is how to incorporate the decisions made by such users (or various committees) into AIS as
decisions are different from numerical data. Then changing regulations and policies cause ‘stress’ on
the existing AIS, if the same is not designed properly. However, HEIs change policies and regulations
Figure 3. Core activities and data flow related to academic term
119
Management Information Systems for Higher Education Institutions
based on strong reasons and existing AIS should be ready to adopt through suitable changes. On the other
hand it is not possible to speculate about future changes in policies to design a 100% flexible system.
One of the modern trends in developing AIS is to provide simple dashboards for this layer of users,
particularly to those who oppose the idea of automation. Dashboards and or data visualization is the
modern way of presenting the information as they simplify a lot of complex scenarios, and present infor-
mation through pleasing graphics. Gurkut & Muesser (2018) clearly points to the fact that information
presented through graphics (or dashboards) reduces uncertainty in the minds of the users.
Requirements of Academic Audit and Quality Assurance Teams
One of the major goals of having AIS is to achieve high productivity and thus be able to secure much
desired regional and international visibility through rankings and accreditation. HEIs spend a lot money,
efforts and resources in this area. Both internal and external audit and quality assurance (QA) teams need
data in wide ranging format specifications. Thus, AIS needs to serve QA teams in principle. Institutional
level quality indicators differ from those of academic programs. External accreditation is generally for
academic programs and thus requirements will be program (or accreditation agency) specific. And then
data requirement specifications vary widely from time to time. Institutional level quality requirements
may not include course details, learning outcomes etc., whereas such details are critical for program level
accreditation. In general, it is not possible to design AIS for this class of users as it might impact the core
design, given the wide ranging (or demanding) and varying requirements. However, IT teams should be
able to provide data and reports from the AIS, as required. Usually such requirements are delivered on
prior notice and through turn-around, time-bound process. On the other hand, if IT teams are forced to
incorporate varying objectives, then design uniformity will be lost; as programs (or departments) have
to be designed differently. It should be noted that automating the core processes to the perfection itself
takes a good while. But the database itself is the core of the AIS and hence applications (which are more
‘read-only’ in nature) can always be developed as and when needed for specific goals without affecting
the core data. In modern times, external QA / accreditation teams are expecting access to electronic
systems to verify the courses, student progress etc. IT teams should be able to create ‘read-only’ views
for the part of the information to satisfy such requests. In such cases, HEIs should have a policy what
information can be shared and what can’t be.
Management Strategy Towards Successful AIS
In most cases, university managements tend to favor in-house development of AIS after the SRS study is
completed. The major reason being the feedback of the internal team that worked towards the SRS study
normally concludes that ‘our requirements are unique and different from others’. Even in cases where an
independent consultant(s) are hired to capture SRS, the final SRS may point towards a typical solution
that meets these identified (unique and different) needs. As far as commercial software solutions are
concerned, pricing of product customization and further support on the customized, tailor made version
can be prohibitively expensive. To be fair to the vendors, such circumstances require them to keep a
team of engineers and computing infrastructure to simulate the user side conditions to provide support
on agreed terms. On the other hand, if universities purchase a readymade off of the shelf solution, then
internal processes (culture and functional processes) need to be altered to suit the newly purchased sys-
tem for successful adaptation. This is where managements find disgruntled users, lower levels of user
120
Management Information Systems for Higher Education Institutions
satisfaction due to natural human resistance to change. This factor of resistance is very well minimized in
case of in-house development with prior information to all, right from the SRS stage to the final stages.
It is a normal practice to appoint advisory committee(s) that is/ are represented by various departments
and units to work on SRS to deployment. With this, most users feel that their views are considered and
by extension they feel part of the AIS that is built in-house. However, it is also common to see opposing
persons or groups to the idea of developing such solution. In such cases management should be ready
with various case scenarios on costs, human resources, importance of having organization owned AIS
and building the brand image. For this, administration should deploy the prototype on a pilot basis in a
chosen department or two to observe its effectiveness. Once results are good, administration is empow-
ered with information on cost cutting opportunities, successful implementation experience from one of
its own departments, factors of new achievements in capacity building and benefits to various users etc.
From the above, the entire process requires a good overall management strategy and planning towards
successful development of AIS.
Moving From a Commercial Software to In-House Solution
In this case too, a comprehensive SRS study needs to be undertaken. However, overall burden of acquir-
ing SRS will be reduced to a greater extent. The sense of confidence of getting back to the existing (or
old) commercial software will be there, just in case of any major failures in developing the in-house
solution. The major tasks in moving usually are changing the backend database, data abstraction layers
and front-end technologies. The ‘familiar look and feel’ of the most screens should be replicated (not
to be copied) with enhanced friendly interfaces to keep the new in-house solution as close as possible
to the hearts and minds of the users. Complicated, slow, and redundant processes (screens) aspects in
existing commercial software have to be identified and users have to be sensitized about the simplified
processes (or improvements) in the in-house solution. Achieving more functionality with rich, ambi-
ent colors is normally the recommended approach on the user front side. However, on the database (or
backend) side important aspects are enhancing speed and simplification of processes without making
compromises in security and efficiency.
Data migration from the old solution to new solution is always challenging and indeed this is a research
area by itself. However, careful planning and an effective data migration strategy will result in complete
success. For this series of queries for data migration, a set of queries for testing and comparing the new
and old data sets have to be identified and the process itself should be verified before going ahead.
Choice of Technologies and Platforms
Choice of technology platforms generally depend on the skills of the AIS development team. It is even
so according to the theoretical proponents of management of software engineering processes. Since it
is related to the skills of individual human beings, there may be range of discussions and arguments on
choice of platforms. However, it is entirely possible to develop large and complex information systems
using open source or license free software platforms and technologies. In general, any information system
will have three tier client/ server architecture that consists of a database (for storing the data), application
layer (for incorporating business logic and processes) and presentation layer (user-interface screens).
Open source database products such as MySql work very well as they have matured enough over the
years and also they do offer more or less same level of functionality and even security.
121
Management Information Systems for Higher Education Institutions
Application layer in AIS consists of implementation of rules, regulations related to various core pro-
cesses of the organization. Typically programming languages such Java or PHP are used since they are
popular in the gamut of internet technologies or programming platforms. There are several Integrated
Development Environments (IDEs) that can be used; but choice may be left to the development team(s).
Presentation layer mostly written in HTML mixed with JavaScript. It is recommended that developers
use only basic and built-in functions/ features of the programming languages as opposed to use external
libraries. In normal conditions, it may not be possible to know if external libraries (that are used) may
be transferring the data of any sort to an external server or entity. Basic functions of the programming
languages can be effectively used to design friendly and secure web pages to present information. Gener-
ally, IT engineers would have common logic building and programming skills in one or two languages
and technology products. Learning a new language or a product becomes easy in a group learning mode
as support from team mates will be available. And when the development work starts on the functional
prototype, developers learn more in the live mode. This type of setting is very common in IT industry
as well.
DESIGNING AIS
Just as SRS, design is also a critical phase. For this, every user, stakeholder, activity, process, input and
output etc., should be identified and then represented in info-graphic form as per the ‘software design
standards’. Core activities should be documented well with appropriate sequence, inputs, outputs, user
actions etc and then populated to various elements (such as database or front-end screen for example)
using simple diagrams. Typical UML notation is used here, but detailed treatment of such notations is
out of scope. Some of the most common design elements include Entity relationship (E-R) diagrams for
databases; logic flow diagrams, definition and description (or purpose) of various objects, functions etc.
The following section takes up a modeling of a typical core activity for the purpose of design treatment.
Typical Academic Term – Core Activity
Courses (taught, supervised and unsupervised etc.), laboratories etc. will have different assessment
components, different criteria for passing. Academic terms are different from institution to institution.
Some universities use three and some use two semesters in a year. A few universities may even use entire
year as one term. Then a few universities follow calendar year for ‘academic year’; whereas a majority
of university may not follow calendar year system. Then the naming of the semesters also varies widely.
In some cases, semesters are simply numbered as I, II and III; whereas names like ‘Spring’, ‘Fall’, Au-
tumn’ for the semesters are also common. Further, the naming convention may change within the same
university. Hence, designers have to be mindful of such possibilities during design and development.
Teachers offering the course(s) may change due to various reasons including retirement.
The fee payable by students is a very dynamic variable. Bulk of the revenue for university systems
come from student fees, government and external grants etc. Hence, this aspect is carefully incorporated
into the design and implementation of the AIS. Ideally, the fee needs to be ‘defined’ (or ‘submitted’)
by the bursary of the university for every academic term that too well before the term commences. This
policy ensures that the fees for various courses are latest and available for students to see through the AIS
when they register themselves. Obviously AIS can help students to plan for the expenses over the term.
122
Management Information Systems for Higher Education Institutions
The window of time for student registration in a typical academic term usually ranges from a month
or two in most cases. A properly designed AIS can help both university management and students to
understand and revisit the financial budgets well before and to make necessary adjustments. Student
registration numbers and historical statistics provide insights into classroom requirements in advance.
Another advantage to the managements is, it is possible to identify the popular courses, which can bring
more revenues into the university system. Usually such popular courses can help the managements to
design new programs due to the obvious demand and expectations of students. Further, university man-
agements should be careful of maintaining academic quality and excellence in those areas of education
in every aspect.
Though there will be many activities, the list below summarizes major activities in a typical academic
term from start to the end.
1. Bursary inputs the fee structure for all the courses, programs, admissions and graduation
2. Teachers (departments/ faculties) input the details of pre-requisite courses, course components,
assessment nature and criteria for all the courses.
3. Respective Departments/ faculties input student criteria for awarding grades with respects to range
of marks earned, rules of academic progression, criteria for matriculation etc.
4. Students register themselves on various suitable courses through the help of AIS itself.
5. After taking the options from the students on registration, AIS must be able to undertake a slew of
checks on the options to see whether student can be permitted.
6. Once registration options are verified, students are notified on the same through email and also
AIS would have updated status based. Then students can pay the fee to complete the registration
process. In some cases, managements preferred that emails should contain phrases like ‘your
registration request status has changed, login into the system to see the details’. In other words,
automated emails are kept as short as possible and in this case, students need to login to the AIS
to see all the details.
7. Towards the end of the academic term, teachers are expected to complete the assessment and submit
the marks into the AIS. It is recommended that AIS to have both automated and manual verifica-
tion of the marks before ‘rolling out’ the final grades. In some cases, it is usually to see ‘tentative
marks/ grades’ which are subjected to approval.
8. Finally IT teams allow AIS to compute ad ‘roll out’ the official results, grades and a number of
reports to various entities for further processing.
9. Academic results are discussed and ‘approved’ by the committees in respective faculties.
10. AIS pushes the data and information into ‘archives’ and gets ready for the new / next term.
The above is a very normal and routine process in most HEIs. However, the overall process and AIS
design and operation are not as simple as it is presented above.
In a typical practical setting, there will be students who arrive late; and managements provide provi-
sions for late registration, albeit with an additional fee; there will be a good number of students who
might request additional time until their scholarships are realized. Cases like wrong registration options;
students who may want to change their registered courses in lieu of other courses; students who may
want to add additional courses may result in close monitoring and updating the databases in a proper
way through an approved process.
123
Management Information Systems for Higher Education Institutions
There are many approaches, methodologies and philosophies for designing any information system. It
is similar to the design processes related to building an apartment complex. Standards may exist but may
vary from place to place. There are several components and stages in the overall development process
from conception to deployment. Different phases, components and even tools that are used have some
standards that are in existence. In the world of software, several design and simulation tools are available
for various purposes such as drawing diagrams, showing data flow etc.
Usually in a practical setting, design process involves identification of core activities, processes, rules
and regulations that need to be applied, input and output data patterns. It is a common practice to draw
a number of diagrams to represent relation between various entities, dimensions, functions, procedures,
sequence of operations, sequence of data flow, conditions or restrictions, even the look and feel of the
user interface etc.
For example, it is a standard to use entity-relationship (E-R) diagrams used to visualize the con-
nections (relations) between the tables in the database layer and also the key parameters in the tables.
Design diagrams do help the development teams in a significant way and also maintenance becomes
easier over the time. Figure 4. shows a typical diagram that combines various entities (students, courses;
policies and regulations; the information system itself and various stakeholders. This diagram severs the
purposes are to display the major entities and also to provide a quick insight into the data flow intensi-
ties so that necessary steps can be taken in various stages of development. It is for this reason, many
previous authors (Soares et al., 2013; Pienaar, 2003; Duan and Zhang, 2007; Riswandi, 2017) have even
provided E-R diagrams and data flow diagrams of the respective systems developed. Design diagrams
are different from one another, and do not follow any specific pattern; though the overall objectives are
more or less same. Further, a few authors (Pienaar, 2003; Motta, 2010) even provided user interface
Figure 4. Major entities in AIS and data flow intensity
124
Management Information Systems for Higher Education Institutions
screens of the systems that were developed by them. Again, those user interfaces are different from one
another. Hence, it is better to follow a design pattern that actually meets the user requirements in the
simplest manner. Just as SRS phase, design phase needs a lot of time and effort since the core activities
have to be properly translated, including necessary provisions for the future and thus making the AIS as
flexible as possible. Design diagrams need to be revised as and when the system is changed as per the
needs or as per the test reports. It is recommended that IT teams use standard and commonly available
design tools to complete overall design phase. Essentially, any AIS is subject to change over the time,
so is the design.
Sometimes, errors made by the departments/ persons in providing course codes or course names;
courses shown as offered, but in reality they are not offered etc., can also put the AIS teams to additional
work in a small window of time, but such incidents do occur even in non-automated environments.
Functional Prototype of AIS
After the SRS study is completed, then starts yet another important phase, “building a functional proto-
type”. For this, management should form a team that champions the overall realization of AIS. This team
ideally should consist of academics, technical personnel, administrators and accountants who support
the cause of developing an information system. The team itself should strongly support the idea that AIS
helps the university community moving forward how the information functions, how it helps students,
academics and other stakeholders of the university, possibility of creating new jobs in managing the
proposed system, financial gains over the coming years, importance of being self-reliant and sustainable
in automating services, factors such as transparency, flexibility, and clarity. For example, accountants
(on this team) should be able to come up with details showing comparison of expenses and benefits (in
tables and projections) between using a commercial solution versus ingeniously built IS. Figure 5. shows
a schematic of a typical prototype.
Similarly, academics on this team that champions IS, should be able to explain the difficulties faced
by faculties, students and then how the new AIS can help in solving the same. Technical team should
be able to explain about the operating processes and training aspects etc.
Then the technical team (which is part of the team that champions the concept of AIS) should develop
a functional prototype, which can deliver most major requirements and also automates key and core
business activities. The major components of a prototype consist of three-tier client/server computer
infrastructure, a well-designed database to store the data, an application layer that captures (or translates)
the core business activities (such as student-course registration, academic progression, submission of
marks and rolling out of the final grades etc.) and also a presentation layer (so called user interface) for
the users on the client machines.
For example, the core business process in an academic term should into the database and applica-
tion layers. Complete user and transactional data from at least two different departments should be
obtained and processed to test the functionality of the prototype. Then a well-designed firewall should
be kept in place to control the traffic and data flow. The entire system should be ready after thorough
testing processes. Special attention should be paid to test the security of the system. For this a few team
members should take up the role of ethical hackers to identify the gaps and to ensure that the system is
adequately secure. Often, testing AIS is tricky, not same as regular software solutions as users of AIS
are very different in their formations. Obviously a significant portion of testing should be done before
125
Management Information Systems for Higher Education Institutions
allowing the users to test the system. All the faults, difficulties and anomalies – however big or small
should be noted and necessary adjustments have to be made to the AIS. Once this is achieved, team
and the administration should deploy the prototype in select department(s). Prototype should then be
revised based on feedback. Then, administration will be in a stronger position to sell the idea of having
in-house developed AIS.
SECURITY OF THE AISs
It is essential that the functional prototype is designed to withstand well-known forms of cyber-attacks.
The firewall is to be tested well to block unwanted requests and traffic in either way. This is the first
step towards building security and in fact security starts with a slew of security checks on functional
prototype. The points below deal with some aspects of the security
1. Processes in case of admissions usually involve inputs from applicants that are totally external
to the university system. There is a high probability of malicious content is being sent. Usage of
separate servers with temporary databases is highly recommended for this purpose.
2. Using external libraries can be a threat as it is possible that some libraries may attempt to contact
external servers for various purposes and reasons. This aspect needs to be resolved before using a
library.
3. Security threats exist even from developers, senior and experienced users, disgruntled persons.
Changing the usernames/ passwords of all IT team members at once are some of the counter
measures.
Figure 5. Schematic of a typical fully functional prototype
126
Management Information Systems for Higher Education Institutions
4. Proper IP blocking policy is very vital. Hackers usually try a couple of times to know the passwords.
Periodical review of user access pattern is important from the security point of view. This task can
be even automated to an extent.
5. Sometimes data integrity issues can appear similar to security threats. Carelessly written code or
database queries can damage too. In systems like AIS, typically several SQL queries will be writ-
ten for various purposes over the time. Sometimes, SQL statements that are written inexperienced
developers can be very detrimental to the data integrity or even for the AIS. Hence, every change
in the code should be verified thoroughly before adopting.
6. Physical security issues will involve factors like properly designed and secured building space for
the IT infrastructure, policy of admission into the IT building facilities, cooling systems etc.
AIS OPERATIONAL CHALLENGES AND PRACTICES
Managing any AIS is a challenge, however small or big it may be. This section deals with some of the
challenges and also practices to deal with in the process of up keeping the AIS. Policies from matricula-
tion to graduation are variable in nature from time to time. Hence this aspect needs to be factored into
design as a variable from academic term to academic term. Once a student is issued with a set of rules
and regulations; then it is not good to change it. For example, required credits (or courses) up to the point
of graduation in normal course of time remains same for a student. However, if a student repeatedly fails
and ‘comes back’ into the system at point where a new policy of regulation may be in effect, then the
new policy applies, so required credits for graduation may change. Such a situation should be carefully
handled by the AIS in terms of requirements and design phases. Solution to such situations depends on
the institutional policies on how the transcript should look, how the student interface should look, how it
should be preserved inside the AIS. It is essential aspect as the academic audits and accreditation teams
look into student progression criteria, and how well the same is applied.
Data Privacy and Sensitivity
Organization policies should clearly define the information sensitivity. IT team managers and HEI man-
agements should be aware of modern trends in data privacy, specifically with General Data Protection
Regulation (GDPR) which is now fast becoming a statutory instrument all over the world. For instance,
questions like “what is private data”? “What is sensitive information”? “Who has access to what”?
“How the right of access is determined”? “How the right to erase information can be granted and by
whom”? - need to be clearly answered by the policies and then policies should be effectively communi-
cated through formal channels to sensitize users. Then, a data protection officer should be appointed to
look into GDPR issues. Also, users should be instructed to report back immediately if they found that
they have access to any sensitive information. It is the first important step in dealing with data privacy
issues. To manage the changing times and policies, a repository of changes in policies and regulations
should be incorporated in the database.
127
Management Information Systems for Higher Education Institutions
Unforeseen Service Interruptions
In case of interruption of services of AIS, it is important that IT team(s) sent out formal communication
to wider university community on possible durations of interruptions and possible date/ time of restora-
tion etc. For this IT teams should have simulated various case scenarios beforehand to estimate the time
of restoration. There are no specific standards of times of restoration(s), as each organization is typical
and unique place and volume of data/ information can vary. So, restoration times are measured during
the test (or simulation) conditions and case scenarios. Based on such experiences, the possible restoration
times are estimated. Most rigorous testing regime will occur on the prototype system. However, the data
volumes grow significantly over the time and AIS gets bigger and bigger. Obviously, there is a need for
testing on a routine basis to understand the restoration process in case of a failure.
Tests on Data Integrity Using Meta Data
This is an interesting area of managing typical AIS. As it is known, data backups or archives are made
periodically and it is recommended that metadata is also collected during the same time. For example,
the metadata may include the number of records of a department or a program or a faculty during an
academic term. There will be several such metadata points to enable cross checks and verifications.
Successful outcome of such testing process will instill confidence in the IT teams on using that specific
data archive.
It is common to see a few types of faults (or events) occur repeatedly on the system. In such cases,
design and implementation parts of the framework need to be revisited. If the situation warrants major
structural changes to the system, then it is the time for planning the next version. Usually the ‘new
implementation part’ be it a design or simply lines of code written by the team(s), needs to be subjected
to rigorous checks for all aspects including functionality, security and performance etc. Such a robust
approach ensures that the future version does not suffer from the same faults.
Preparedness of IT Teams
High availability, reliability, dependability and integrity are some of the essential aspects of any well-
managed information system. For this preparedness of the IT team(s) is very critical. The team leaders
must have complete knowledge of maintenance activities and turn-around times. Several management
strategies exist for determining the level of preparedness. For instance, team leaders / managers must be
able to answer a few questions like a) how long it takes for a complete backup of the AIS? b) There is a
service interruption and how long it takes to determine the root-cause? c) Who are responsible for what?
d) How long it takes for complete restoration from a data archive? e) What is the process (procedure) to
update a part of the code? f) What is the frequency (or policy) to take data backups and how are they are
stored? g) When is the next version due? h) What are the compelling (and non-compelling) reasons for
working on the new version? i) Are the new features in the next version? j) What is the testing criteria
for the new version? k) What are the training requirements and burden on users when the new version
is released?
128
Management Information Systems for Higher Education Institutions
On the security aspect, the IT team leaders must have clearly defined answers for questions like a)
who is responsible for passwords and overall security? b) What are the security checks to identify pos-
sible intrusions into the system and how frequent such checks? c) What is the process if a minor (or
major) intrusion is detected?
The above questions are not exhaustive, but only to provide basic idea on keeping the IT teams up to
date so that they are prepared for any eventuality.
Cooling Systems
Servers and data storage systems need uninterruptible cooling. In case of failure of cooling system, com-
puter infrastructure is subjected to thermal stress and thus causing loss of information. Proper safety and
alternate cooling arrangements must be planned in advance for such an eventuality. This type of threat
will exist irrespective of the fact that whether software is a commercial type or developed in-house. This
is more of logistics planning than a software aspect.
FOLLOWING AND APPLYING STANDARDS
Following standards in software applications is a major point of discussion. Applying standards to ev-
ery aspect may not be wise especially for a system that is purpose built. This is especially true in case
of providing elaborate security measures given the sensitivity nature of the data and information. User
comfort and cyber security should be prioritized more than applying standards. However, the AIS team(s)
will get several opportunities over the time to standardize (or to optimize) the system. Even in some
cases, overall design may warrant significant change due dynamically varying nature of the academic
systems. Hence, processes like optimization or standardization can be taken up at a later point in time.
Documentation for both internal and external use is done in every phase for various purposes. Usually
documents are classified and separated properly for internal and external uses. For instance, design
documents are for internal consumption of IT teams only. Following any one known standard such as
ANSI (ANSI, 2019), ISO/ IEC/IEEE (ISO, 2019) for every phase of development is very essential. Most
standards are simple and easy to follow, but even the standards have different purposes. For example,
standards exist specifically to align development team members, or for the testing personnel to follow.
Such a document will enhance clarity in the development process. Especially, documentation helps new
recruits of IT teams in a significant way. Documents for external use generally will have content related
to the policies on services, rights of users, policies related to GDPR, expected standards of service etc.
Effective documentation and adherence leads to high quality AIS in long run.
CONCLUSION
This chapter has presented various important aspects of AIS applicable to HEIs from the conception to
deployment. Well-managed AIS not only helps in automation but also serves in advancing the reputation.
User requirements will vary from university to university and hence it is difficult to expect a university
to use a readymade, commercial software solution that is not manufactured with specific client require-
ments. On the other hand, designing and developing software that suits requirements of organization is
129
Management Information Systems for Higher Education Institutions
the recommended approach since it can cut costs to a significant extent. After all, HEIs are the custodians
and manufactures of the talented and highly skilled human resources. By taking up in-house develop-
ment option, HEIs will be able to understand strengths and weaknesses of their core business processes;
and thus can take appropriate corrective actions even during planning phase. Hence, there are several
opportunities exist; besides challenges. Several academic institutions have successfully developed in-
house process automation solutions. It is high time and imperative that HEIs, make an effort to use the
in-house talent to build their own AISs, if they don’t yet have one.
REFERENCES
Abdul-Hamid, H. (2014), “What Matters Most for Education Management Information Systems: A
Framework Paper”, Systems Approach for Better Education Results, Saber working paper series No.
7, World Bank Group.
Al-Mamary, Y. H., Shamsuddin, A., & Nor Aziati, A. H. (2014). The Relationship between System
Quality, Information Quality, and Organizational Performance. International Journal of Knowledge and
Research in Management & E-Commerce, 4(3), July.
Aldarbesti, H., & Saxena, J. P. (2014). Management Information System for Education. IOSR Journal
of Research & Method in Education, 4(1), 36–44.
Alyoubi, B., & Alyoubi, A. (2013). Impact of Academic Information Systems on the Performance of the
Higher Education Institutions, 2(2), 32–37.
ANSI. (2019). “Software Engineering”, Retrieved from https://webstore.ansi.org/industry/software/
software-engineering
Bernbaum, B. M., & Moses, K. (2011). EQUIP2 Lessons Learned in Education - Education Management
Information Systems. USAID - A guide to Education Project Design, Evaluation, and Implementation
based on experiences from EQUIP2 Projects Malawi, Uganda and Zambia.
Duan, R., & Zhang, M. (2007). Design of Web-based Management Information System for Academic
Degree & Graduate Education. IFIP International Federation for Information Processing, 252, 218–226.
doi:10.1007/978-0-387-75494-9_27
Felson, J. (2015). The Low-Hanging Fruit of Technology in Academia - Is technology in academic
advising a help or a hindrance?, American Association of University Professors. Retrieved from https://
www.aaup.org/article/low-hanging-fruit-technology-academia#.W9enV5NKhPY
Fredrick, O. O. (2017), Influence of Use of Education Management Information System (EMIS) on
Management of Secondary Schools in Nairobi City County, Kenya. (PhD thesis submitted to University
of Nairobi).
Gurkut, C., & Muesser, N. (2018). Important Factors Affecting Student Information System Quality and
Satisfaction. EURASIA Journal of Mathematics, Science and Technology Education, 14(3), 923–932.
130
Management Information Systems for Higher Education Institutions
Indrayani, E. (2013). Management of Academic Information System (AIS) at Higher Education in The City
Of Bandung. Procedia: Social and Behavioral Sciences, 103, 628–636. doi:10.1016/j.sbspro.2013.10.381
ISO. (2019). IEEE 12207-2017 - ISO/IEC/IEEE International Standard - Systems and software engineer-
ing -- Software life cycle processes. Retrieved from https://standards.ieee.org/standard/12207-2017.html
Karim, A. J. (2011). The significance of management information systems for enhancing strategic
and tactical planning. Journal of Information Systems and Technology Management, 8(2), 459–470.
doi:10.4301/S1807-17752011000200011
Luena, A. M. (2012), Strengthening the Education Management Information System (EMIS) in Tan-
zania: Government Actors’ Perceptions about Enhancing Local Capacity for Information-based Policy
Reforms, Scholarworks, University of Massachusetts Amherst. Retrieved from https://scholarworks.
umass.edu/cie_capstones/21
Lupu, A., Bologa, R., Sabau, G., & Muntean, M. (2008). Integrated Information Systems in Higher
Education. WSEAS Transactions on Computers, 7(5), 473–482.
Montoya, S. (2018), Data for Sustainable Development - Why We Need Effective Education Management
Information Systems. Retrieved from https://sdg.uis.unesco.org/2018/04/10/why-we-need-effective-
education-management-information-systems/
Motta, S. M. (2010), Design of a Comprehensive Student Information System (SIS) and User Interface
for the Honors College at USF, Scholar Commons, University of South Florida, Outstanding Honors
Theses, Paper 43. Retrieved from http://scholarcommons.usf.edu/honors_et/43
Ommundsen, S. O. (2017). Designing an Education Management Information System, (Master Thesis,
University of Oslo).
Pienaar, H. (2003). Design and Development of an Academic Portal. Libiri, 53, 118–129.
Riswandi. (2017). The Development of a Computer Based Education Management Information System
(MIS) Model in Elementary School Bandar Lampung, Al-Ta Lim Journal, 4(1), pp. 9–18.
Sastry, M. K. S. (2007). Development of an academic information system for effective education man-
agement. International Journal of Management Education, 1(3), 276–286.
Soares, R. P., Sediyono, E., & Pakereng, I. (2013). The Analysis of Academic Information System
Design of IPDC Dili - Timor Leste by using EAP Approach. International Journal of Computers and
Applications, 84(15), 4–11. doi:10.5120/14650-2921
Sudirman, I., Govindaraju, R., & Pratiwi, A. A. (2014). Information System Quality and its impact on
individual users’ benefit: Analyzing the role of knowledge enablers. Journal Teknik Industri, 16(2), 65–74.
Tahvildarzadeh, M., Moghaddasi, H., & Hosseini, M. (2017). A framework for quality management
of university educational information: A review study. Res Dev Med Educ., 6(1), 3–11. doi:10.15171/
rdme.2017.002
131
Management Information Systems for Higher Education Institutions
Vann. (2012). The challenges encountered while developing and implementing education management
information system. Retrieved from https://www.kenyaplex.com/resources/6552-the-challenges-encoun-
tered-while-developing-and-implementing-education-management-information-system.aspx
Zilli, D. (2014), Self-service business intelligence for higher education management. Intl. conf on Hu-
man Capital without Borders, Slovenia. pp. 1387–1393.
