Three Box Principle

As a software architect, my primary job is to define an architecture, framework, or a platform for my clients. The expectation is that the framework or platform will be generic, modular, and flexible as soon as it's created. It does not work that way.

For the sake of this article, I'll use the term 'framework' to define frameworks, architectures, and platforms and the implementations you would do on top of them as 'applications'.

When I started my career as a software consultant, my first gig was at Bell Labs - the famed R&D wing of Lucent (now Alcatel) technologies. As a young Java programmer imbibed with GoF patterns and other similar literature, I was ready to spit out architecture all around me! When I attempted one such 'framework' for the project I was working on, I soon realized that my framework was not as flexible or as modular as I had hoped it would be.

One day, while sitting at the library in Bell Labs, I came across a book (or article) that talked about the three box principle. The principle essentially is that it takes at least three attempts or revisions to make a framework generic.

I have attempted to reproduce the principle in the diagram below.

The principle has an important corollary - "You cannot build a framework without building sample applications that utilize or implement the system." Most IT teams tend to create an "architecture" team who would create architecture by considering the overall goal of the company and then impose it on the applications used within the company. Such elitist attitude is doomed to fail, as it does not consider the ground realities of the applications and eventually the maintainers of the applications will tend to find ways to circumvent the architecture rather than use it, beating the purpose of the architecture in the first place.

In contrast, the best way to build a framework is to work with the applications, including them iteratively while developing the framework itself, which is what the principle suggests.
By the principle, in the first box or phase, you pick one or two candidate applications and build them. At this point, you are not worried about the framework. You are just developing the applications with a vision of the framework in the background, but not really doing anything conscious about it. This phase should then be deployed and field-run for at least a few cycles (months, weeks, etc.)

In the second box/phase, you pick few more applications and try to add them to the first set of applications. At this point, some patterns will begin to emerge due to the commonalities between the applications. You still don't consciously build the framework, but rather refactor the common libraries and features so that they are more modular. You might end up following principles of inversion of control around this time. By this time, you would have also seen the feedback from real customers and noticed the pain points of the initial applications and would adjust the features accordingly.

In the third phase, you add some more applications to the system. At this stage, there will be enough common functions/features that you can modularize further and see a much stronger pattern that would enable you to separate out the framework and setup the applications on top.

I have personally seen both sides of this principles - the success stories when this was followed and the failures when it was not. So, next time when someone asks you to build a framework, try to set the expectation that frameworks are more like a pastry from a master chef rather than a frozen microwave dinner. It takes time and multiple tries to make the end-product perfect.

PS: I believe the book I read was Implementing Application Frameworks by Mohammed Al Fayad, although I couldn't find a reference in the book. Maybe it was an article from the same author - I am not sure. If anyone has read this article, I would greatly appreciate it if you can drop in a comment with the right source.