Of edges and vertices - another stab at reaching a more systematic view of software

I keep hearing, services (as in SOA) are about edges. If that´s the case, what are these edges connecting? There are no edges without vertices.

At this point, I don´t yet want to speculate about what the vertices or "bubbles" in the picture are. But I guess I know one thing: they sure have a structure.

What about services now? Does each of the connections between the inscribed bubbles also have to do with services? I don´t think so. At least not necessarily.

And are those bubbles now atoms? I don´t think so either. I guess they again can have some structure:

Every bubble is just a functional unit of a software and exists on a certain level of abstraction. The above pictures thus show a stepwise refinement process start at some level n of abstraction and moving down to level n+1 and then n+2. As long as the bubbles are not mapped to some concrete software artifact (e.g. a class) this process can continue pretty much ad infinitum. You choose which bubbles need to be refined more until you feel confident as to clearly understand what a leaf bubble in this hierarchy does/means.

But not only bubbles or vertices can be refined. Edges can be refined too:

And within the edge refinement, again edges and bubbles can be decomposed and so on.

What do we know now?

• Software consists of a set of "bubbles".
• Bubbles live on different levels of abstraction.
• Bubbles are vertices in a mesh woven by edges between bubbles.
• Edges live on different levels of abstraction.

And what don´t we know yet?

• What is a bubble?
• What is an edge?

Following Bertrand Meyer´s famous "Bubbles don´t crash" I´d say, we need to map bubbles to very concrete software artifacts, otherwise they are prone to become stale as soon as their implemenation changes. To paraphrase Bertrand Meyer I´d additionally say "Edges don´t break" unless we map them to very concrete software artifacts.

This leads to the question: Which software artifact to assign to an edge or bubble?

Classifying Edges

To reach an answer, we first need to specify, what an edge is: An edge is a communication line between bubbles. Bubbles implementing some partial functionality (of a higher level bubble) need to cooperate and thus need to communicate. How the communication is done is defined by an edge thru its technology (e.g. WCF), its mode (e.g. async) etc.

What kind of communication is approriate is a function of firstly what the connected bubbles do - not of how they are implemented. So before determining the exact software artifact for a bubble, I´d say it´s best, to define their communication and general relation. Does the communication need to very fast? Does it need to be synchronous? Does it need to be secure? Do the bubbles "know" each other very well, do they trust each other? Is a certain bubble required to be located on a particular machine? All these questions can be answered without exactly knowing yet, what a bubble is.

The result is an architectural image of a software with different "weights" attached to the edges:

How bubbles are related can be expressed by different styles for edges (thick/thin, dotted/dashed/solid, color) and proximity, suggesting the closer together two bubbles are drawn, the more intimate their relationship.

What can happen when you start classifying the edges is, you find that two bubbles, originally being close together because they were the result of the refinement of an encompassing bubble, move farther apart. Maybe you even feel inclined to move them apart:

That´s perfectly ok. Software design is an iterative process. And if you discover some system property only later in a process, that´s ok. Most important than is to stay in the world of software artifacts and refactor your design and not gloss over your discovery.

Enter services: You just put a lot of thought into the edges of the system. That´s essentially service oriented thinking already. Because by weighing the edges depending on the general functionality of the connected bubbles, you thought a lot about coupling and autonomy of the bubbles. What a service is thus does not so much depend on its representation (what kind of software artifact is used), but on its relationships with other bubbles.

A service simply is a manifest bubble on some level of abstraction exhibiting properties aligning it with the tenets of SOA. Since autonomy (i.e. very loose coupling) is at the heart of the service definition, service bubbles are even pretty free to move around in your architecture. Take the purple bubble in the above picture as a service: first it worked pretty close to other bubbles within a shared container bubble. Then it was moved out of the container to work stand alone. What changed was just the classification on the edges connecting it to other bubbles.

So, what do know about edges?

• Edges connect bubbles for them to communicate.
• Edges have properties that need to be specified in order to map them to the world of software artifacts.

What are properties of communication edges? Here are some coming to my mind, but sure there are more:

• Mode: sync, async
• Style: RPC-style, message based
• Direction: unidirectional, bidirectional
• Proximity: do both bubbles run in the same address space?
• Transactions: is the communication transactional?
• Security: does integrity and/or privacy need to enforced?
• Latency: How long does a signal need to travel between the bubbles
• Bandwidth: How many bubbles can communicate via the connection at the same time?
• Contract: Which operations with what kind of data can be started?
• Technology/API: System.Net, System.Remoting, WCF, ADO.NET, System.Messaging, System.IO, etc.

Classifying Bubbles

Now on to the bubbles. How can we "root them in reality"? Let´s start by finding the lowest level of abstraction we can equal with a software artifact. I´d say that´s a single statement. When decomposing a software system you don´t want to go deeper than single statements in whatever language you´re later on using for implementation.

On the other end of the spectrum of abstraction levels is a solution, I´d say. Because when you set out to design a system, you do that with a solution for a particular problem in mind. You customer usually does not request "a class" from you. She´s not concerned with such nitty gritty details, but rather just asks you for "a solution".

Ultimately a Solution thus consists of Statements. But as we all know, it´s impossible for any non trivial problem to get from the problem definition to the necessary statements in just one step. Instead we need to stepwise decomponse the problem - or the Solution bubble as its representation.

For this stepwise decomposition (which is an iterative process and can be top-down as well as bottom-up) we need more levels of abstraction between Solution and Statement. I propose the following Application, Component, Assembly, Class, Method with more or less obvious manifestations.

Each level of those software artifacts corresponding to a level of abstraction can contain many artifacts of the next lower level and itself is part of a container artifact. Following Arthur Koestler these artifacts can be called holons arranged in a holarchy.

The above picture hopefully looks simple and systematic to you. From my experience in using it with customers I can at least say, it helps a lot in designing software systems (or Solutions for that matter). To have a continuum of abstraction levels at hand is a very convenient guideline for your struggle with complexity.

However, I´d like to add some refinements to the picture:

A context for Solutions

Even though what you need to develop is a Solution and thus is the root for the tree of software artifacts you need to produce it is helpful to see a Solution in context, i.e. to see it too as part of a larger whole. I call the container for Solutions a Society.

The Society simply spans a space in which to locate your Solution (which needs to be designed by decomposition) as well as other, already existing Solutions or systems of some kind that are of importance to your Solution. Your Solution of course communicates with the others in some way, otherwise it would make no sense to depict them at all. However, the other Solutions are black boxes. No details can or should be known about their inner workings. What counts is only the edge between your Solution and them.

Outlook

Ok, so much for today. Next time I´m gonna talk about processes and recursive software building blocks.

For those of your, who already heard of my models called Software Universe and Software Cells, what I wrote here should have sounded very familiar. That´s of course on purpose :-) But stay tuned, because you´ll find out, I´m trying to move on and make the Software Universe even more valuable and easy to use.