Software Cells #8: Of Customer Problem Domain and Infrastructure - Mind the Dimension

After I put Software Cells into perspective with other architectural models, several people approached me with the question "Now, then, what are Software Cells for?" followed with some problem scenario. And I can tell you, those scenarios made me sweat for a while ;-) But I want to spare you the details and focus on my findings while trying to put Software Cells to good use on those problems.

First of all to answer the question: Software Cells currently are just about helping you to model a solution in software to a problem. That´s why at the center of Software Cells are physical Software Solutions as a set of Software Cells aka Applications. One problem = one Software Solution. For example the problem is "Build an online shop", then a Software Cells model would contain several Applications distributed across several computers, e.g.

Software Cells want to help you model the distribution of your logic. Since Hosts and technologies for communicating between Hosts (Adapters/Portals) are explicit entities in the Software Cell world, the force you to make concious decisions:

• Across how many hosts do I distribute my logic?
• Which Hosts do I choose?
• How do I do I/O in and between my Software Cells?

But what if I find, my solution needs some multi-protocol load balacing server? Or what if I find, that the interplay between several Cells in my application becomes very complex? Is there only one level of abstraction in a Software Cell diagram? Is there only one problem domain dimension in my model.

For simple to moderately complex problems I´d say yes. That´s where Software Cells came from. And that´s the problem space most of my customers usually live in. Their Solutions consist of maybe 1 to 4 Applications on average.

But if the problems become larger you need to be able to structure them more. Remember the motto of the ancient Romans: divide et impera ;-) You need not only to modularize one Solution but also the whole large problem. So as a first step I´d say: chop your problem up in sub-problems. For each sub-problem develop a Software Solution. So what you end up doing is developing a Software Society. The modules of very complex software are not assemblies or Software Components (consisting of several assemblies), but Software Solutions.

You have a small/medium problem, you develop one Solution:

You have a much, much bigger problem, you split it up into sub-problems and solve it with several Solutions:

But still, each Solution focusses on solving a customer problem - albeit this can happen on different levels of abstraction.

The first two questions above (concerning a multi-protocol load balancing server and the complex interplay of Cells), though, are not concerned with solving a customer problem. They are concerned with infrastructure. For most problems all the tools you need probably already exist. There is an array of powerful Hosts and there is a large number of communication technologies to choose from. Choose the right Host and write Adapters/Portals to make the I/O APIs palatable to the logic Cores of your Applications. Depict Hosts in your Software Cells diagram, label the connecting edges between your Hosts with the communication technologies used - but otherwise don´t show any infrastructure. The MSMQ server is necessary for using the System.Messaging API - but there is no place for it in a Software Cells diagram. It´s transparent to your Applications. Likewise a load balacing server. Software Cells in so far are a logical model and don´t show deployment configurations. If a IIS/ASP.NET based Software Cell later on runs on multiple hardware servers with a load balacer distributing requests among these instances is not of concern to the Software Cells model.

However, large problems can hit the limits of existing technologies. You could find an existing load balacing product too limiting (or even don´t know of it ;-) Or you could find repeating patterns in your Solutions with respect to the communication between the Cells that begs for a generalization.

So what can happen is, you try to fill a gap in the infrastructure. And although infrastructure programming usually should be avoided it sometimes might be necessary. So what can you do? How does the Software Cell model help you?

I´d say, Software Cells can help you in two ways:

1. Software Cells give you a clear framework to categorize the infrastructure you´re thinking about. Do you need a better communication infrastructure? Or do you need a better Host? Very often the lacking infrastructure belongs to one or the other category. The above missing multi-protocol load balancer falls into the category of communication infrastructure because it connects Software Cells. On the other hand, a relief for the complex interplay of Applications could fall into the category of Hosts and could be called a "Business Process Server" (something like BizTalk).

2. Software Cells diagrams let you depict your overall solution along several dimensions: customer problem dimension, communication infrastructure dimension, and Host infrastructure dimension. (And I guess, there could be even more dimensions.)

For each infrastructural entity you decide to develop you have to ask yourself:

• Is it just an API I need to write, e.g. a general abstraction on top of System.IO maybe?
• Or do I need to accompany the API with some kind of server, e.g. for load balacing? (A new server without its own API on the other hand does not make much sense, I´d say.)
• Or do I even want to have my own server run problem domain logic, i.e. do I need my own Host?

System.IO is an example for just an API. System.Messaging is an example for an API that also needed a server (MSMQ). And .NET Remoting is an example for an API and a server which also is a Host.

Once you identified the infrastructural pieces you need to solve the original customer problem, I´d say, set up separate projects for them and solve them independently from the customer problem. What you then get is some kind of Solution hierarchy along the above dimensions. Here´s a picture for a 2-dimensional Solution:

Along one dimension you see the "regular" Solution to the customer problem consisting of two Software Cells which communicate using some concrete I/O API. However, since you developed that API and provided an infrastructure for it, you know, it´s only a logical connection.

The physical connection runs along the infrastructural dimension or - so to speak - on a different level which is not directly seen by the problem domain Software Cells. For them the new infrastructure is transparent and hidden behind the new API.

The bottom line: Software Cells provide a model for any software. But beware to put too much into a single Solution diagram. If Solutions become too complex, split them up and start developing a Society. If you´re realy, really missing infrastructure, then separate these concerns from the customer problem domain and set up distinct projects with their own solutions - which you later fit into the "main" project as infrastructure "components".