School Administration Software: Central System

We contributed to a school administration software project that was built and further developed as a central system for administration and cross-agency connectivity across Berlin’s school system. The project was carried out for a client responsible for delivery on behalf of a public-sector end customer. Our focus was on the frontend architecture, coordination with the end customer, processes for changes and releases, and modernising the existing codebase.

Initial situation

The assignment came from a client delivering the project for a public-sector customer. What was needed was a central system for administration and cross-agency connectivity across Berlin’s school system.

Within the project, our task was to provide technical leadership for the frontend architecture, coordinate implementation with the end customer, and further develop the team’s working foundations. This also included structured processes for changes and releases, as well as modernising the existing codebase.

Solution

We took on technical leadership for the frontend architecture based on Angular and TypeScript and aligned the architectural decisions with the end customer. For the user interface and browser application, this placed our work in the area of web development.

In addition, we trained the developers and supported ITIL-compliant change and release processes. ITIL is a framework for clearly defined procedures in IT service management. We also migrated version control from TFVC to Git and modernised the codebase.

The project ran from April 2019 to July 2021 with a team of 3.

Result

What was delivered was our contribution to a central system for administration and cross-agency connectivity across Berlin’s school system. This included the technically led frontend architecture, coordination with the end customer, developer training, support for change and release processes, migration from TFVC to Git, and modernisation of the codebase.

The project was completed after a duration of 28 months.

Technology

• Angular for the frontend architecture of the web application
• TypeScript for frontend implementation
• Node.js as part of the technical stack
• Telerik for user interface components
• NgRx for state management in the frontend; this provides a structured way to manage an application’s state
• TFS and Azure DevOps for development and deployment processes
• MS SQL Server for data storage
• ITIL v4 as the basis for ITIL-compliant change and release processes

Why school administration software needs clear structures

In projects like these, school administration software usually has to do far more than simply digitise individual workflows. The typical aim is to bring together different responsibilities, multiple participating bodies and requirements that grow over time within one shared system. Especially in public-sector environments, it therefore makes sense to clarify architecture, responsibilities and change processes at an early stage.

One key point is the functional structure of the application. If areas such as master data, roles, workflows and reporting grow together without order, further development quickly becomes difficult to manage. A robust frontend architecture helps divide the interface into clearly separated parts. That makes later enhancements easier, improves collaboration between several developers, and reduces the risk of changes in one area having unintended consequences elsewhere.

A clean approach to application state is just as important. State management means that the software keeps clear track of which data is currently being loaded, changed or checked. This is especially relevant in extensive line-of-business applications where many screens, filters, permissions and processing steps interact. Without such rules, hard-to-trace errors are far more likely to arise.

For similar projects, the organisational setup also plays a major role. In practice, changes do not just have to be developed; they also need to be assessed, approved and rolled out in a controlled manner. Structured change and release processes ensure that requirements, fixes and new features move into live operation in a traceable way. Release processes are the procedures used to plan, test and deploy new software versions.

Modernising existing systems is also typical in administration software. Many projects do not start from scratch, but build on existing solutions. In that case, it is often sensible to first bring order to the codebase, version control and development workflows before moving on to larger functional expansions. This creates a solid foundation for day-to-day operation and future development.

Anyone planning a similar project should therefore look not only at features, but equally at architecture, change processes, maintainability and collaboration between the business side, the client and the development team.

How projects for line-of-business applications like this typically run

For line-of-business applications of this kind, a project usually begins with a joint clarification of the starting point, responsibilities and target vision. Especially where a contractor is delivering for a public-sector end customer, it is important to define communication routes and decision-making rounds clearly. This makes it visible early on who evaluates functional requirements, who prepares technical decisions and who grants approvals.

During the concept phase, the usual focus is on describing which workflows the system should support, which data should be maintained, and where other authorities or organisational units are involved. In parallel, the structure of the application is planned: which areas will be separated from one another, how permissions will be handled, and how changes should be implemented in future. For browser-based line-of-business applications, this often also includes planning database development, interfaces and data migration, because data models and connections to other systems have a major influence on the application.

This is usually followed by implementation in coordinated work packages. Regular alignment with the business side and the client helps clarify functional questions early and avoid misunderstandings. In projects like these, it makes sense not only to make architectural decisions internally, but also to document them transparently and discuss them with everyone involved. This applies in particular when an existing system is being modernised or when the team’s way of working is being changed.

The implementation phase often also includes setting up or adapting development processes. This covers version control, traceability of changes, approvals, and structured handovers into testing and operations. Modern version control makes it easier to develop changes in parallel, merge them, and review them in a traceable way.

Before go-live, there are typically quality assurance, acceptance and operational preparation activities. Quality assurance means systematically checking functions, data flows and user workflows. This is followed by the controlled transition into live operation with clear responsibilities for support, fixes and further development.

Anyone planning a similar project can sharpen the scope at an early stage by preparing the requirements in a structured way. A project check or a no-obligation initial consultation is well suited to clarifying the task, open points and the likely scope of the project.

Typical stumbling blocks in operations, interfaces and changes

In projects like these, the greatest risks often lie not in individual functions, but at the boundaries between business requirements, technology and organisation. One common stumbling block is unclear responsibility. If it is not clearly defined who prioritises requirements, approves changes or answers business-related questions, delays and contradictory decisions arise.

Another critical point is interfaces and data. Interfaces are technical connections to other systems through which data is exchanged. In cross-agency processes in particular, data fields, responsibilities and update rules must be described clearly. Otherwise, media discontinuities, duplicate maintenance or conflicting data states can easily occur. Migrations should also be prepared carefully so that legacy data, histories and business-specific nuances are not lost.

Within the application itself, permissions and traceability are particularly important. A system in an administrative environment generally has to reflect different roles, responsibilities and processing statuses. It should therefore be clarified early on who may view, create, change or approve what. Logging changes is equally relevant so that processes remain traceable. The specific legal requirements that apply in each case should be reviewed with the responsible bodies and, if necessary, with legal advisers or data protection officers.

Operations also deserve attention early on. It is not enough to develop an application; it must also be provided reliably, monitored and further developed. This includes structured procedures for changes, releases, error correction and technical maintenance. If cloud operation is planned, responsibilities, security measures, access and operational processes should all be considered from the outset. Information on hosting and operation in the Microsoft Cloud helps to assess the operational aspects in a structured way.

Finally, maintainability is often underestimated. When teams grow, responsibilities change or new requirements are added, unstructured code quickly becomes a problem. That is why it pays to maintain architecture, naming, tests and development processes consistently. Anyone preparing a similar project should treat these points not as side issues, but as a fixed part of the project.