27. September 2024
By Dr. Nikola Milanovic
The first time I read “small is beautiful”* in a computer magazine, one that was very popular in the eighties, I was attending elementary school and starting (or trying) to teach myself how to program. I don’t remember what the text was exactly about, probably because I also failed to understand most of it at that time, but the phrase “small is beautiful” somehow stuck with me.
Later in professional life, I came across it many times, even while learning about modular engineering principles at university. And still, on my first job, I was assigned the task of creating a media import tool and ended up writing a “god class” of more than 1,000 lines of code. This happened for several reasons. I was fresh out of university with little real-world experience, the requirements were unclear or even unknown (“Here, take these 10 CDs with images and import them until Friday.”), edge cases and escalations happened later which required quick fixes without much thinking and so on.
Even later in life, I discovered the importance of clear architectural principles. Prioritizing non-functional properties like performance, security, and fault tolerance over features is key. Coupled with continuous refactoring, this approach helps create products that run with minimal failure rates, scale well and have zero serious security issues.
At the same time, I saw products exploding and failing because much more was tried than was necessary. Too many functions, too many stakeholders, too many “must-haves”, too many “we need that, too.”
When we started developing yuuvis® Momentum at OPTIMAL SYSTEMS a few years ago, we agreed on a small but fixed set of non-functional properties. We agreed that no matter how complex the future requirements become, we will never implement them in a way that breaks those basic properties. For example, we agreed on a minimal import rate for a given cluster size. If any future feature were to break this rate, it would be reimplemented, moved out of the core product or simply rejected.
We also introduced the concept of “onion architecture.” At its heart, the system’s core—or the center of the so-called onion—must guarantee the agreed-upon non-functional properties at all times, without compromise. All services in the core are essential for the system to run properly and follow the principle of “small is beautiful.” Other functions that are built around the core, like the layers of an onion, can be peeled away without affecting the system’s operation. While these layers should also uphold non-functional properties, they may, by conscious decision, break them for a specific use case. However, this must never jeopardize the entire system; other functions must not be affected by such compromises.
This sounds very easy to do “on paper.” Living this decision in everyday work is difficult, and oftentimes it is necessary to make a compromise. We tried to make as few compromises as possible along the way. It also helps having a chief software architect on the team whose favorite quote is “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”** This is why today yuuvis® Momentum is a very powerful ECM platform, built for the cloud, with many exciting features, such as audit-proof records management, powerful search, intelligent schema, flexible workflow, fast security system, integrated AI and much more. Despite these advancements, it still boasts almost infinite scalability, remains maintainable and is just as fast and secure as a few years ago, when it was “merely” a very fast document repository.
Small is indeed beautiful.
* Small is beautiful is the first basic tenet of the Unix design philosophy by Mike Gancarz
** Antoine de Saint-Exupéry
OPTIMAL SYSTEMS is a
Group company of
Kyocera Document Solutions.
General Remarks
Software & Services
LOCATIONS