Software Architecture for Fiji National University Campus Information Systems

Software Architecture defines the overview of the system which consists of various components and their relationships among the software. Architectural design is very important in the development of large scale software solution and plays a very active role in achieving business goals, quality and reusable solution. It is often difficult to choose the best software architecture for your system from the several candidate types available. In this paper we look at the several architectural types and compare them based on the key requirements of our system, and select the most appropriate architecture for the implementation of campus information systems at Fiji National University. Finally we provide details of proposed architecture and outline future plans for implementation of our system.

💡 Research Summary

The paper presents a systematic approach to selecting an appropriate software architecture for the Fiji National University Campus Information System (FNU‑CIS). It begins by outlining the functional scope of a modern university CIS, which must integrate student registration, academic records, finance, human resources, and other administrative processes. The authors identify three distinct user groups—students, academic staff, and administrative staff—and enumerate the specific tasks each group must be able to perform through the system (e.g., online application, profile management, course enrollment, grade viewing, fee payment, staff‑led enrollment, report generation, etc.).

Recognizing that the choice of architecture profoundly influences non‑functional qualities, the authors define six key quality attributes: accessibility, security, performance, flexibility, scalability, and maintainability. Four widely‑used architectural styles are examined: (1) client‑server, (2) component‑based, (3) n‑tier, and (4) service‑oriented architecture (SOA). For each style, the paper provides a concise description, typical use‑cases, and a qualitative assessment against the six attributes. The assessment is summarized in a comparative table, where each attribute is scored on a low‑medium‑high scale.

The analysis shows that the n‑tier style consistently receives the highest scores, especially in scalability and maintainability, due to its logical separation of presentation, business logic, and data access layers. Client‑server scores poorly on scalability because of its reliance on a single central server. Component‑based approaches improve deployment ease but lack robust support for high‑volume transactional workloads. SOA offers excellent reusability and portability but introduces considerable design complexity and runtime overhead that may be unnecessary for a university‑scale system. Consequently, the authors select an n‑tier architecture as the most suitable foundation for FNU‑CIS.

Deployment considerations are then discussed. Two options are contrasted: distributed deployment (each tier on a separate physical machine) and non‑distributed deployment (all tiers co‑located on a single server). While distributed deployment provides dedicated resources and stronger isolation, it also adds infrastructure cost and operational complexity. The paper opts for a non‑distributed deployment for the initial rollout, arguing that it simplifies management and reduces cost, while still preserving the logical tiered structure that can be refactored into a distributed layout if future load demands require it.

The technology stack decision focuses on the choice between Microsoft .NET and Java Platform, Enterprise Edition (Java EE). .NET offers a rich class library and tight integration with Windows platforms, but its ecosystem is largely Windows‑centric. Java EE, by contrast, is an open, cross‑platform standard with mature APIs for persistence (JPA), messaging (JMS), web services, and enterprise beans, making it well‑suited for multi‑tier, fault‑tolerant applications. The authors advocate Java EE for FNU‑CIS, emphasizing its portability, extensive tooling, and alignment with the university’s likely heterogeneous server environment.

The final architecture diagram depicts a three‑tier logical flow: a web client (browser) interacts with a web server, which forwards requests to an application server that implements business logic, and finally to a relational database server for persistent storage. Security is handled primarily at the server side, with the database isolated behind the application tier. The paper concludes by outlining future work: performance benchmarking under realistic load, a migration path from the initial non‑distributed setup to a fully distributed n‑tier deployment, and the incorporation of additional security mechanisms (e.g., firewalls, intrusion detection) and monitoring tools. Overall, the study provides a clear, requirement‑driven methodology for architecture selection and offers practical guidance for implementing a robust, maintainable campus information system.