Software Cells #B: Keeping the Essence of Software Layers

After I had written my previous posting about the Software Cell dimensions I kinda felt a little bit ashamed for my software layer bashing ;-) So what I now want to try is get back on board all those who left in dismay. Here´s my message for you:

If you like those terms frontend, businesslogic, and data access so much and find them usefull - well, then you can continue to use them with Software Cells.

For example, simply assign the Components of an Application to the logical categories of Frontend etc. That´s perfectly fine. You can do that even accross holons and on any level of the holarchy, if you like:

This way the value of software layers is retained: a way to categorize code to solve the customer´s problem. But at the same time, the limitations of software layers are avoided: you´re no longer limited by a stack of layers where the world has moved on from stacks to networks of entities.

The strict order of software layers as well as their limited granularity has outlived itself. But the main message does not need to die but can live on in Software Cells: Mind what your code is about! Is it about frontend oriented stuff? Or is it just logic? You name it - no, better, you categorize it. Put it in a logical category like in the picture above. I´d even say: invent any number of them as you like. If it helps you to structure your problem´s solution, it´s all fine.

Just beware of mixing up logical categories with dimensions. A category is a group of holons within (!) a dimension. A dimension is another type of "category" (or space) for holons, whose functionality is orthogonal to other dimension´s holons.