{"id":396109,"date":"2024-09-27T12:02:16","date_gmt":"2024-09-27T10:02:16","guid":{"rendered":"https:\/\/www.optimal-systems.de\/?p=396109"},"modified":"2026-07-28T08:34:44","modified_gmt":"2026-07-28T06:34:44","slug":"small-is-beautiful-non-functional-properties-in-complex-software-systems-or-why-we-built-yuuvis-momentum-this-way","status":"publish","type":"post","link":"https:\/\/www.optimal-systems.de\/en\/digitalization\/blog\/small-is-beautiful-non-functional-properties-in-complex-software-systems-or-why-we-built-yuuvis-momentum-this-way","title":{"rendered":"Small is beautiful: non-functional properties in complex software systems OR Why we built yuuvis\u00ae Momentum this way

"},"content":{"rendered":"\n

<\/p>\n\n\n\n

<\/span>\"An\"An
\n
\n
\n

Date<\/span><\/p>\n\n\n\n

Small is beautiful: non-functional properties in complex software systems OR Why we built yuuvis\u00ae Momentum this way<\/h1>\n\n\n\n

By Dr. Nikola Milanovic<\/p>\n<\/div>\n<\/div>\n<\/div><\/div><\/div>\n\n\n

\n
\n
\n

The first time I read \u201csmall is beautiful\u201d* 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\u2019t remember what the text was exactly about, probably because I also failed to understand most of it at that time, but the phrase \u201csmall is beautiful\u201d somehow stuck with me.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n

\n
\n
\n

From \u201cGod Class\u201d to Clear Principles<\/h3>\n\n\n\n

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 \u201cgod class\u201d 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 (\u201cHere, take these 10 CDs with images and import them until Friday.\u201d), 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 \u201cmust-haves\u201d, too many \u201cwe need that, too.\u201d<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n

\n
\n
\n

Non-Functional Properties as the Foundation<\/h3>\n\n\n\n

When we started developing yuuvis\u00ae<\/sup> Momentum<\/a> 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.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n

\n
\n
\n

Onion Architecture: The Heart of yuuvis\u00ae Momentum<\/h3>\n\n\n\n

We also introduced the concept of \u201conion architecture.\u201d At its heart, the system\u2019s core\u2014or the center of the so-called onion\u2014must 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 \u201csmall is beautiful.\u201d Other functions that are built around the core, like the layers of an onion, can be peeled away without affecting the system\u2019s 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. <\/p>\n\n\n\n

This sounds very easy to do \u201con paper.\u201d 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 \u201cPerfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.\u201d** This is why today yuuvis\u00ae<\/sup> 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 \u201cmerely\u201d a very fast document repository.<\/p>\n\n\n\n

Small is indeed beautiful. <\/p>\n\n\n\n

* Small is beautiful is the first basic tenet of the Unix design philosophy by Mike Gancarz<\/p>\n\n\n\n

** Antoine de Saint-Exup\u00e9ry<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n

\n
\n
\n
\n
\n

Do you have any further questions?
Contact us!<\/h2>\n\n\n