The Architect´s Napkin

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

My Links

News

Archives

Post Categories

Software cells as large scale building blocks

The basic building blocks of software when you start architecting it are... well, not classes, and no UML packets either. I believe it should be something more high level and general.

Classes are too fine grained to be used as architectural modelling elements. No chip architect would start planning a new processor by arranging single transistors, and no building architect would plan a house by thinking about where to place each brick:

image

Such a detailed view of a house might be nice for home owners to give them an impression of how their house will look. So it´s about the look and feel and has always been an art of its own:

image

source: http://upload.wikimedia.org/wikipedia/commons/c/ca/Erlach_4.jpg

Using the almost lowest level structural elements for planning how something is built, though, works only for very, very simple things. Think of a flip-flop circuit or a shepard´s hut:

image image

sources: http://pics.computerbase.de/lexikon/121846/180px-Flipflop_by_trexer.png, http://www.planetfear.com/includes/images/uploaded/24200746122613JP-stone-hut.jpg

As a software architect you need more coarse grained material to form an application out of. At least to start with. Do rough sketches first, then refine them. Start in the large, then drill down into the small.

But what is a structural element of software in the large? A UML package? I don´t find that very useful out of two reasons: On one hand an UML package has close ties with a particular programming language (Java), and why should I as an architect be concerned with that (at the outset)? On the other hand an UML package is something very generic, too generic, I´d even say (think UML stereotypes), and why should I as an architect be not more specific?

Hence I feel there´s a lack of an appropriate structural element for modelling software in the large. Services, too, do not help. They are an application of structural elements. So what I came up with are software cells. To me they are the basic, rough, and coarse grained modelling elements for architecture in the large. Their depiction is simple as I showed in my previous posting:

image

Now, what is a software cell? Well, a software cell is a larger unit of code. It can be just C# code or it can be the sum of C# plus T-SQL plus IronPython plus Java plus VBA. The only criteria to call something a software cell is: you develop the code. So basically the "membrane" separates your code from the rest of the world, from some environment.

image

You could also think of a software cell as an island of your code that´s separated from other code islands or some mainland by large stretches of water:

image

How much of your code goes into a software cell? At the beginning, it´s all the code you´re going to develop for an application. From 30,000 ft your application always looks like one large softwar cell:

image

But then, when you sink lower, zoom in during your planning, when you refine your picture of the application, then you come to see more details. The one island of code in fact is several islands:

image

This way you build your software in the large on an arbitrary number of levels of abstraction. Here´s a more handy tree view of such nesting of software cells. It´s the stepwise structural decomposition of the root software cell, which - in the beginning - was the sole representation of the application to plan:

image

Each level of this tree contains as many software cell as you see fit. All together they describe your application on different levels of abstraction/detail. But they are just "blobs of your code" representing some kind of task or responsibility on a high level. Except for the leaves of such a tree of nested software cells they are all virtual or logical. They exist only on your napkin and in your head. Their purpose is to keep complexity at bay.

The leaves, though, are real. They are operating system (OS) processes (or .NET AppDomains if you need more than one in an OS process). So the goal of the initial architectural phase is to determine which OS processes your application should consist of.

Since all applications require at least one OS process to run their code in it´s always right to fill the first blank napkin with a software cell. You could even draw it before your boss has started to explain what kind of application he envisions. With a software cell on your napkin you´re never wrong. Be it a "Hello, world!" program or an ERP system.

This might sound trivial to you, but my experience with lots of software teams tells me, it´s far from it. Many, many developers have difficulties to find an entry point into a software architecture. What they fall back on in such a situation are... more or less formal UML class diagrams. That´s like starting to plan the Empire State Building with some door or corner stone. Or it´s like planning a painted portrait by drawing an ear lobe. Maybe some master artist can start like this, but not us mere mortals. For us it´s much easier not to start with a detail, but with a big picture right in front of us - on the back of a napkin. That´s what software cells are about.

Software cells are the large scale building blocks for our applications. With them you can quickly refine your picture of a software from initial code blob containing everything you need to develop to a number of OS processes among which you distribute the code. Here´s a series of napkins as a testimonial to this approach:

image image image image

I began the architecture with just a single software cell to represent all of the application to develop. As I said, that´s never wrong.

Then I decomposed the software cell into two very different ones, e.g. a software cell for frontend stuff and one for business logic stuff. Maybe I first thought a client/server architecture would fit the problem best.

But then I realized it would be better to distribute the business logic stuff across at least two software cells, both being candidate OS processes.

Finally I devided the frontend stuff into two software cells (or candidate OS processes), because I learned from my boss, he would like a web frontend as well as a desktop frontend.

And, upps, before I forget, there is another concern coming up: What about reports? If the application needs to print long running reports they could be produced by yet another software cell (aka service) instead of one of the business logic software cells. So I spawn another software cell from the code I imagined to go into the blue software cells:

image

This is the lowes level of abstraction at the end of the first architecturing phase. These software cells are now to become the OS processes of the application. And depending on who you´re talking to you can pull out an appropriate napkin on a level of abstraction right for your audience.

Here´s the decomposition for you as an overview of all levels:

image

With your senior developers you talk on level 4, the OS process level. The newly hired junior dev might need a more gentle introduction to the application starting on level 2, and your boss or his customer just wants to see the big, big picture on level 0.

In any case: If a napkin gets crowded by symbols and lines, take a new one from the pile. Insert a level of abstraction and drill down using a couple of napkins for the details.

Ok, where are we now? I showed you how to start architecting you next application not by trying to dream up some class it might contain, but rather by determining the OS processes it will be distributed across. That´s maybe just one or it´s a dozen on several machines and different platforms. Start by assuming there is at least one, depict it as a software cell, then refine each software cell in a recursive process into "smaller", more focused software cells until you´re confident you´ve reached the leafs of the software cell tree. That´s the OS processes.

Print | posted on Thursday, June 12, 2008 5:23 PM |

Feedback

Gravatar

# re: Software cells as large scale building blocks

I think this looks like a great, practical approach to design. What was drilled into our heads in art class was: "Work general to specific". When painting, drawing, sculpting, etc., you always start with the general shapes, etc. of the entire picture, then gradually build up the entire painting.

In software design, I could see the same being useful. I'd love to see a real world example blogged out here...
6/12/2008 9:06 PM | Daniel
Gravatar

# re: Software cells as large scale building blocks

@Daniel: That´s what I mean: from the general to the specific, from the outside to the inside, from the big picture to the details. When facing uncertainty it´s better to start rough and the refine whereever you feel comfortable. It´s not a one way street, though. You can do jo-jo architecting ;-)
6/12/2008 9:15 PM | Ralf
Gravatar

# re: Software cells as large scale building blocks

Great articles! I like the approach.
Just one tought - I hope you'll show in the near future how to deal with repeatable "cells" in cells. I mean at some point every cell will have - for example - some interface, or "facade" - this is quite common design to use when you need several systems to communicate.
Are you going to draw a "facade" in each cell that needs it, or is it on some other level? Or maybe I am totally wrong and you'll never have cells like my facade :)

cheers!
6/13/2008 12:17 AM | mYsZa
Gravatar

# re: Software cells as large scale building blocks

"Repeatable cells"... hm... what does that mean? Even though nothing speaks against re-using a software cell, e.g. deploy it several times with the same application, I don´t understand what you mean by "repeatable cells".

Of course software cells have an interface, and I´m going to talk about that quite a bit. But why would that make a cell "repeatable"?

What you call "facade" I call "portal". But that´s a story for a posting of its own ;-)
6/13/2008 9:26 AM | Ralf
Gravatar

# re: Software cells as large scale building blocks

"Repeatable cell" - I mean something that is a single cell that you want to show on every level of abstraction - let's take for example a logging system. Does your model allow to use the same cell - logging system - on few different levels (e.g. level 2 and 3), without breaking the cell into smaller pieces? I know it's very abstract question :) But I simply do it all the time, and sometimes was wandering if someone has a better idea. For some reason it doesn't "smell good" to me :)
6/13/2008 11:55 PM | mYsZa
Gravatar

# re: Software cells as large scale building blocks

@mYsZa: I see what you mean: Yes, software cells can appear on more than one level of abstraction. If on level n there a 2 software cells C1 and C2 and you decompose C1 into C1.1 and C1.2 thereby creating level n+1, C2 will also be on level n+1, if it´s not broken up. See the last drawing in the posting: the rightmost software cell belongs to levels 2 to 4.
6/14/2008 9:04 AM | Ralf
Post A Comment
Title:
Name:
Email:
Comment:
Verification:
 

Powered by: