The Architect´s Napkin

Software Architecture on the Back of a Napkin
posts - 69 , comments - 229 , trackbacks - 0

My Links



Software cell - What´s in a name?

Software cells to me are the basic building blocks of software in the large. Don´t think in smaller terms as a software architect - at least at first. Keep your planning on the process level or above, e.g. on the service level. Services - as in SOA - can be depicted as software cells, too. You can think of a service as a composite consisting of several smaller software cells.

As peel away the layers of your software system, your application starting from the top, i.e the whole application...

image get to the layer of services...


...which you can drill down into to get to the actual OS processes constituting these services:


(Please notice, how a service from the previous/higher level has become an OS process on this level. That´s because the service just needs one OS process. No further refinement was needed.)

Software cells thus lend themselves not only to planning a single application, but also to think in SOA terms. Which brings me to the question: what is it, that makes a software cell a software cell? Why the similarity to biological cells? Why didn´t I choose another analogy?

At the core of the cell analogy is, well, the core. A core of something sitting in the middle of an area surrounded by a wall.

Let me explain the genesis of this analogy: It was in 2005, I guess, during a vacation in beautiful Ireland, when I toyed around with software architecture depictions. I was pretty much in a trance the whole time - much to the grief of my girlfriend. The driving force behind my thinking was distress with the architectural layer pattern. Layered architectures or N-tier architectures seemed inflexible and misleading to me.

First of all, they suggest a certain direction of development. You´re either a person who likes to start with the tangible and visual, so you emphasize the presentation layer. That where you feel comfortable. So you work yourself from there down to the invisible parts you might be so sure about anymore. Or you´re a person who likes to lay a solid foundation. So you start at the backend, the data access layer and work your way up to the frontend.


Either way what´s kind of left out by these "processes" is the most important part of any application: its busines logic. Although the literature always underlines its importances, this message often does not materialize in project reality which is driven by one of the personality types just described. This is because the layer pattern does not favor any layer. All layers are created equal, so to speak.

So my first approach to improving the architectural pattern/symbol situation was to morph the layer pattern into a "burger pattern":


It changes the importance and the priority in favor of the business logic. That´s where the meat (!) is of an application. That´s the area you should flesh (!) out first. Business logic should be developed in a way as to be pretty invariant with regard to how it is access from any frontend or what kind of backend it uses to retrieve/store data. Frontend technologies change all the time, so do backends. Yesterday we used ADO.NET, today it´s some O/R Mapper, tomorrow it might be an only storage service like Amazon´s S3 or SimpleDB. Would you want to modify the business logic along with those changes? No, I don´t think so. That´s why it´s more important to think about it first, to put it in the center of your planning.

Then I played around with those "burgers" (even though my mother used to tell me, "Don´t play with your food!").  Here´s what a multi-layer application looks like:


And here´s an N-tier application:


But wait, isn´t that the same picture as for a multi-layer software? Yes. The reason is, that N-tier diagrams, which are just multi-layer diagrams, usually don´t graphically distinguish between a layer and a tier. They assume you know, that in an N-tier diagram a layer is at least an OS process.

I think, that´s bad, because it leads to falling prey to one or more of the "fallacies of distributed computing." So at least, when you know you´re dealing with different OS processes, pull apart the layers/tiers and connect them with arrows like this:


Unfortunately that raises some questions: Is all the code in a tier of the same color? If so, where do you put validation code, for example? Validation sure is a business logic responsibility. But you don´t want to be forced to do all validation in the green OS process. Some validation should already be done right after data entry in the frontend. But that would mix blue code with green code. Or you might want to validate data right before storing it, just to be sure. That would mix red code with green code. Not a beautiful sight, or is it?


But the shudder that ran through me when I saw this "distributed burger" led me to an insight: business logic is not limited to the "middle tier", but can appear in all tears. That´s not even an exception, but the norm. You should not avoid it, because it´s so natural.

Unfortunately the N-tier architectural pattern does not account for such naturalness.

So, what to do? Avoid putting business logic in the frontend or backend (e.g. as a stored procedure) and thus not be able to model what´s coded? Or spit into the holy grail of distributed systems modelling, the N-tier pattern? Tertium non datur?

After having a Guinness or two I chose a third way: I did away with layers and tiers.

Instead I made what seemed awkward in the N-tier model the center of a new model: If we business logic is so important and we can´t avoid putting business logic in all tiers, why not put business logic at the heard of everything - plus give a tier a distinct shape?


Isn´t that straightforward? Each circle represents a tier (and thus readily distinguishes itself from a layer), each tier/circle contains business logic.

Thinking further along this line then led me to the visual unification of "all tiers are created equal". From a structural or syntactic point of view there is no difference between a presentation tier, a business logic tier, and a data access tier. So why not represent them using the same symbol?


This was the birth of the software cell. The dot in the middle signifying the ubiquitous business logic.

Syntactically it is on par with the simple box of a tier. But semantically is has more to offer:

  • A software cell makes clear, at least an OS process is meant when it´s drawn.
  • A software cell makes clear, at the core of every OS process is the business logic.
  • A software cell makes clear, business logic can be present in any OS process.
  • A software cell makes clear, there is a gap between them that needs to be explicitly bridged. (Tier boxes on the other hand could be just stacked, not leaving a gap, and thus glossing over the fact, that communication between tiers has different characteristics than communication between in-proc layers.)

In addition the circle of a software cell allows for more flexible connections with other software cells. Drawing distributed systems - which are increasingly becoming the norm - thus has become much easier with software cells instead of tier boxes.

And think of it: What a great analogy to think of software systems consisting of many processes as "tissues" made up of software cells. Why not seeing such service tissues as "organs" of an even larger software system or "software organism"?


By making business logic core and making OS processes as well as OS process aggregates clearly visible in an architecture, it´s easier for autonomy - one of the fundamental values of SOA - to enter the picture. Software cells are code units running all by themselves in a separate physical or logical address or data space. They share, so to speak, the same "milieu" (alluded to by the colors of the "tissues" in the above drawing).

You decide, how much business logic to "lump together in a software cell organ" until autonomy "sets in". Physically a single software cell representing an OS process is already autonomous in so far as it´s running on its own thread in its own address space. But logically, with regard to the problem domain, though, it might not be able to truely act autonomous. Nevertheless it´s on a good way, because it´s naturally decoupled from other software cells. But that´s a topic for another posting.

Let me close by making again clear, how software cells lend themselves to describing software systems on different levels of abstraction by adding levels above the previous drawing:

image image

On which level does the software system or its parts become autonomous with regard to the respective environments? It´s up to you - as it always has been. But with software cells it´s easier to "visually think" autonomy, because the very concept of (semantic) and symbol (syntax) for software cells carry autonomy at the core.

Take a software cell, connect it to another, connect both to yet another... there is no limit to the connectability of a software cell. Model strictly hierarchical software or P2P software in the same easy manner:

image image

Software cells don´t restrict you syntactically. You´re free to shape the topology of your distributed system as you like. That´s freedom the N-tier paradigm does not offer. That´s why I saw the need for a new, more flexibel meta-model for larger scale software structures.

Let me close for today by saying, that it´s of course ok to use boxes in software cell diagrams, too. If you like, group software cells on any level by surrounding them with a box or any other shape of your liking. That way you can add dimensions for e.g. platform, machine, or some logical context:


Just be sure not to overburden the napkin with details!

Print | posted on Friday, June 13, 2008 10:07 PM |



# re: Software cell - What´s in a name?

Hi ralf,

It's great to read all this again in a... hmm... let me call it tidy manner. I'm very exicted on your explanation about protal/adapter.

Yesterday I introduced a new staff - and i stumbled about a question.

Let assume you have a client and a server.
(The arrow points from the client to the server, is this correct, because they communicate with each other?)

<img src="" border="0" width="465" height="507" alt="" />

So now, there is also an outlook add-in. How is this drawn? It's hosted in its own os-process. I wrote it. But it's hosted in outlook? How to draw this?

go on - it's great, i like it so much to work with your "SOP" ;-)

kind regards
6/16/2008 12:05 AM | Laurin

# re: Software cell - What´s in a name?

Does the comment feature work? I wrote a comment more than 24 hours ago.... and it is still not displayed.
6/17/2008 9:15 AM | Laurin

# re: Software cell - What´s in a name?

@Laurin: Sure, the comments work - but they are moderated. This might take a day or two.

As for your scenario:

-If you´ve two software cells and call them client and server to express an asymmetry between them, yes, then the connecting relationship´s arrow should point from client to server. The client is calling/controlling the server. (I would draw a client on top or to the left of a server, though. It´s the established direction of reading.)

-How Outlook is drawn depends on its role. Is Outlook accessing the server as well? If so and you´re gonna write logic code to be hosted in Outlook, then Outlook also is a software cell. If, on the other hand, you don´t need to touch Outlook, then it´s an actor or a ressource - depending on whether it calls a software cell or is called by one.
6/17/2008 10:11 AM | Ralf

# re: Software cell - What´s in a name?

oh - ok... sorry i didn't know that the comments are moderated. it tolds me that "it will be displayed soon".
But it seems to work great ;-)

thank you. everything is clear. so outlook addin should be an software cell, in my case.
6/17/2008 11:24 AM | Laurin

# re: Software cell - What´s in a name?

@Laurin: In my opinion, Outlook with enclosed Add-In could be drawn just like Ralf started with the first images on top of the posting to depict breaking down services to actual OS processes. The custom tailored Outlook solution as a whole appears as single entity (1 cell) to the server/users but splits in sub-cells on a par, if you take a closer look = the common Outlook features themselves and the added abbilities of the Add-In, both cells communicating with each other. This fits perfectly when you have more than one Add-In, thus more than 2 cells within the Outlook organism!

@Ralf: At this point, I asked myself why the cell division analogy stops at the OS process level. In the example above, Add-Ins are executed within the Outlook process but could resp. should be considered as cells of itheir own in my eyes. Right?
6/17/2008 8:08 PM | Hans

# re: Software cell - What´s in a name?

@Hans: You got me there: Why do cells stop at the OS process level? Well... they don´t :-) But this is one of my most recent insights.

Software cells can be nested inside OS processes. But then: what is a software cell? I´ll explain that in my next posting, I guess. Not stopping with them at the OS process level in fact made the explanation of software cells easier.

For now let me just say: Despite all that two add-ins within Outlook probably are not two software cells. But that depends on their, hmm, "operation mode". Rather mostly likely they are "just" components.

So I´m happy if you like the software cell concept. But beware: not everything is a software cell ;-)
6/17/2008 8:57 PM | Ralf
Post A Comment

Powered by: