There are several shortcoming in the DHIS 1.x line which is linked to the limitations of MS Access and the style of development it supports. This limitations is the primary reason it was decided to make a total reimplementation of DHIS. I will explain several of the limitations in this section.
MS Access is a Rapid Application Development (RAD) tool where the focus is more on facilitating fast application development than it is on making the application maintainable. As a consequence DHIS 1.x is not very modularised. The user interface, consisting of forms and reports, is tightly integrated with VBA scripts and database tables. The DHIS 1.x strain is primarily developed by one small team in South Africa. Because of the “onion architecture” of the software only the development team leader, Calle Hedberg, understood the software in depth. The term “onion architecture” reflects the fact that the software was step vise expanded and improved according to user demands. This changes was made layer upon layer, creating tight dependencies between different part of the software. MS Access naturally lend itself to this style of programming. The design of DHIS 1.x have not been done in splendid isolation, but the development is and has been done by one small team.
DHIS 1.4 fixed some of the architectural problems the previous releases had. This version is, however, still limited by the MS Access platform. MS Access is not made with a open distributed development process in mind. MS Access is as a RAD tool primarily developed to support application development by one programmer, or a small team of closely cooperating programmers. MS Access is in other words designed to support small scale cathedral-style development. To harvest the collective capabilities of the HISP network it was decided to base the development of DHIS 2 on a community model. To facilitate this the core of DHIS had to be built on a modular base.
A serious limitation in MS Access is the maximum size of the MS Access database, a single database file is limited to 2GB. At the central level in South Africa the database size was closing in on this limit. The MS Access database is not designed to handle many simultaneous requests and therefore do not scale well according to the number of users. Neither to MS Access scale well according to the size of the database. This is mostly solved by the possibility to transfer the database to a better DBMS in DHIS 1.4. Still DHIS 1.4 relies on the MS Access user interface which looks simple and out-dated. The user interface is clearly improved in DHIS 1.4 compared to 1.3, but is still limited by MS Access. A fancy user interface is not important for the functionality of the system, but is important to the overall user experience.
Turning our attention to the internal architecture of the DHIS 1.x it should be noted that MS Access is built around a two tire architecture. There is a user interface tire with forms and reports and there is a database tire with tables and queries. The business logic is spread into both the user interface tire and the database tire. The current best practice for database applications is to use a three tire architecture which clearly separate between user interface, business logic and the database. This architecture is easier to change and extend, and is better for distributed development.
The DHIS 1.x strain is a stand alone desktop application and the only way to transfer data between each instance of the application is through exporting and importing of data files. For larger offices with several people doing data input and analysis it requires some effort to export and import data between the different DHIS installations. It would be easier to have a central database accessible by LAN. To support different use scenarios ranging from a single installation to a corporate LAN it was decided to web-enable DHIS.
The cost for MS Office and MS Windows licenses was not an issue in South Africa when DHIS was first implemented, because MS Office and MS Windows was already in widespread use. The MS Windows and MS Office combo is commonly available in developing countries, with or without a license, so the cost savings argument have up until now not been a strong argument. This can change as Microsoft shows more interest in emerging markets, and because of international agreements like the TRIPS agreement.
Basing an application that is supposed to be used by many different users in different contexts on MS Access gives several challenges. MS Access is clearly not designed for this. Even the basic boolean values; true and false, have different representation in different localisations of MS Access. The update life-cycle of MS Office and MS Windows makes it necessary to support a matrix of MS Office, MS Windows and language combinations. We experienced this in Ethiopia with the column separator issue and the issue with the ICD extension to DHIS, making DHIS only compatible with the XP version of MS Access.