The Minitel Paradox

Minitel was great. It was internet before internet. I was envious on Minitel as a kid and as a teenager because I was able to read about it therefore I was dreaming of using it someday. Minitel was an tightly integrated solution that was sized precisely for its purpose. The terminal, the access network, the services were perfectly matched together. The overall usage experience was great.

In the meanwhile, before web, there was a myriad of BBS solutions, more or less reliable, more or less updated. The experience of using them was ranging from "meh" to awful. But they were not integrated at all, they had no specific access network, terminals and servers could be run on any hardware. It was mostly patchworks but the system worked. Then the "black swan" event happened and, in almost no time, WWW and internet emerged globally. The BBS systems rapidly evolved in browsers and websites, access networks transitioned from dial-up to fast FO or 4G. And everything evolved to what we have today.

The highly integrated Minitel stayed the same in the '90s and after, not being able to keep up with the rapid developments of web. Sadly, it was finally shut down in 2012. Minitel's flaw was that it was too well engineered. That it had perfectly fitted parts. But when everything works as expected there is no drive to change it. It is better to have in some situations sub-optimal parts but clear and open interfaces because this forces evolution. And evolution leads to survivable systems.

This was a long intro. My story today is about very skilled friend that created microservice templates with everything built-in. They were batteries included, as Minitel once was. Everything was inside, whether one was using it or not and integration in the system required that every microservice having the same structure. A perfect match. Almost as good as Minitel. My opinion on his idea was: "Let there be chaos". Create interfaces and let service developers hook into them as necessary because it is hard to control business needs and technology stack evolution. Hence both implementations and interfaces can evolve separately. It would be an evolutionary patchwork as with internet. The only restriction is to keep interfaces open. His templates were fantastic. Out of the box messaging, smart logging and metrics, Kubernetes ready - checked, any nowadays technology was there with a clear scope - current business needs. But, as I remarked to him - current business needs, interfaces and contracts were defined inside template not outside of it, changing an interface required to rebuild all the services or creating many adapters that in the end will require more mapping an translation logic.

Coming back to my debate, on a smaller scale keeping his solution will work flawlessly for a while but it won't evolve. It will freeze the technology stack and it will break "Favor composition over inheritance" dogma - because the system will hardly find spare parts that fit together and can sustain the evolution. Also skill sets evolve from ANSI control codes in BBS to React. It's uncommon to find ANSI gurus in the younger generations.

If we raise the question "How would a Minitel world respond to COVID-19 situation? Home office use cases, collaboration, and so forth?" Would it be even possible? My guess would be: NO. Because the associated costs of changing a tightly integrated solution would be times higher than changing parts of a heterogeneous and open solution (imagine the costs of changing every terminal and link at a global scale).

Engineering systems should find balance between perfect and perfectible and accept perfectible yet incomplete components and as architects we should deal with evolvability as one of the important NFRs.

Interestingly, Minitel started evolving after it's shutdown in 2012 when open innovation was possible: https://opendna.com/blog/2012/06/30/the-end-of-minitel-its-past-and-our-future/