Modular PhD

The basic idea of modularity is not limited to software design. Indeed, modularity finds its inspiration in many natural and social phenomenae. Baldwin and Clark (1997) transfer the concept of modularity to management in an impactful research article published in the Harward Business Review (see Baldwin and Clark, 1997). They distinguish three design rules elemental to modularity:

(1) The system should be guided by an architecture, which specifies modules and their functions.
(2) The system should define interfaces, which moderate the interactions between modules.
(3) Standards for testing of compliance with 1. and 2. should be defined to measure the level of compliance.

Here, I want to discuss the question whether these design rules can also be applied to the „system“ of a PhD thesis.

Most notable, in many disciplines it becomes more and more common to do a PhD by publications. Usually, a PhD conducted in this way consists of three related journal articles (Single, 2010). However, the precise regulations vary from university to university; with some requiring printed top journal publications while others do not require the articles to be published at all. Some programmes also allow the incorporation of conference publications.

Writing the PhD in such a way inevitable requires to think modular; the PhD consists of three related parts rather than one enormous whole. Modularity poses many advantages, where the most important might arguably be the reduction of complexity (Baldwin and Clark, 1997). I might believe that writing these related articles might often be easier than approaching the PhD project as a whole.

However, a number of problems need to be addressed to conduct a complex research project as a PhD in a modular fashion. Following the three design rules listed above, one needs to consider:

(1) Do I need to define an overall architecture for the PhD defining the individual parts and their purposes? When do I need to define this „architecture“?
(2) What are the relationships or interfaces between these individual parts and when do I need to define them?
(3) Can I employ a framework to assess and assure the overall coherence and quality of the work?

The first two questions lead quickly to issues of adaptivity. Traditionally modular systems were designed in a hierarchical fashion; where the overall systems could define the framework for the parts. However systems designed in this way have been found to be not very adaptive. Changes in the parts might very well impose a necessity to change the overall design framework.

I believe this especially holds true for research. Research is all about the discovery of new knowledge. How can we anticipate of the outcome, if, by definition, we do not know this outcome yet. Some disciplines might be in the comfortable position to have a finite set of possible outcomes. However, most problems faced nowadays are far too complex to be reduced a forehand to a number of possible solutions as what we discover „on the way“ or through the lens of our knowledge gained in the process might proof far more interesting than what we initially aspired to investigate.

We can try to design a more adaptive system by designing modules in a specific way (D’Souza and Wills, 1998). We can, for instance, try to make the modules as independent from each other as possible.

However, this very much opposes the idea of many thesi where one significant research questions is under investigation by employing a single methodology in a robust way.

These questions lead me to the issue that a modular PhD first requires a modular and adaptive conceptualization of research. With research being in many ways like any project, one might expect that adaptive and modular methodologies are readily at our disposal. However, most methodologies I came across do not seem to discuss this issue to a great extend.

Maven Eclipse Plugin: Update MANIFEST.MF (Eclipse Problem)


As I have written earlier, I copy the MANIFEST.MF, which is generated by the Maven Bundle Plugin into my eclipse PDE projects.

The problem is that eclipse PDE has problems with picking up the contents of the newly created MANIFEST.MF.


One solution I have found is to simply open the MANIFEST.MF in eclipse and click on one of the import‘s properties.


Afterwards, the MANIFEST.MF can be saved and the PDE will pick up the contents of the MANIFEST.MF and do a syntax check, etc.


Sometimes eclipse does not recognize that the MANIFEST.MF is to be opened with the Plugin in Manifest Editor. In that case, right clicking and selecting open with / other is helpful.


Maven Bundle Plugin Configuration

In a previous post, I have provided an example of a possible Maven configuration to use the maven eclipse plugin with eclipse PDE. Besides these settings, which are the same for every project, each bundle needs to be configured as OSGi bundle in order to be usable by eclipse PDE.

                <></> <!– Maven groupId –>
                <></> <!– Maven artifactId –>
                <module.version></module.version> <!– Maven artifact version –>

The project settings need to to be specified later in the pom:


The remainder of the pom is composed of the elements necessary for the maven eclipse plugin and and the following additional Maven bundle plugin.

                        <!– FOR BUNDLE MANAGEMENT –>
                        <!– The Maven bundle plugin generates Meta-data required for OSGi –>