Software Cells #A: Embracing Infrastructure

At the beginning of my journey into Software Cells was an uneasyness about the term "application". It seemed, developers were not all too clear about it. Now, as it turns out, I feel the same about "infrastructure". My impression is, in software projects distinguish not enough between problem domain and infrastructure. By that I don´t mean, nobody takes into account a HTTP like IIS is needed to host the code of an intranet application. And of course all developers are aware they have to rely on an OS or even some other runtime.

What I mean is a distinction for the code you write yourself. Developers are used to categorize their code along the software layer model; so they split the solution up into frontend code, businesslogic code and data access code. But when it come to security, validation, caching, internationalization etc. they have a hard time to tell, where this belongs to. The software layer model then offers to put it somewhat on the side:

But this is an after thought of the software layer model. There was no infrastructure in the picture at the beginning and if you look at the literature, infrastructure is treated differently or not at all. Examples: for Robert Chartier is is part of the layers (see his proxy tier), or Malveau and Mowbray don´t paint infrastructure into their pictures at all.

I now think, this is very contraproductive, misleading and causes confusion among developers. A completely different view of software is necessary, where the distinction between primary problem domain (the customers problem we need to solve) and any infrastructure needs to be a top priority.

Since the software layer does not offer any clear means to intregate infrastructure into the whole picture of a solution, it is another sign of its little use today. Software layers had their time back in the 1990s when they provided a more structured view on software; they were one of the first architectural patterns following new technological options like easy network communication, HTTP server, and application server.

Before the layer model there were just software monoliths - maybe accessing a database server with some stored procs. But they lacked an explicit and generally accepted categorization of their functionality (although being based on OOP principles).

Software layers back then were a valueable step forward. But they failed to stay abreast with further technological developments, since at their heart still was a single "application" (or Solution in Software Cell terminology). Software layers are not made for networks of Solutions/Applications where there is not a strict front to back communication.

But these kind of applications are now state of the art and they also require more infrastructure. They require more OS and runtime infrastructure, but they also require you to develop more infrastructure code like for caching or accessing user preferences.

That´s were Software Cells claim to fill the gap. As has been shown they easily allow you to depict complex architectures on different levels of abstraction. However, so far, the message on infrastructure has not been so clear. That´s what I want to change today by saying:

Software spans a multilevel and multidimensional holarchy (or universe, if you like). (The following picture only shows the top 4 levels, the remaining levels Assembly, Type and Methods are left out just because it was easier to draw it like this ;-)

That means, each holon is a multidimensional entity.

Each holon can consist of holons in several dimensions. Unfortunately it´s hard to draw more than three dimensions, so I´ll adopt a somewhat unusal style from here on, which allows me to depict at least 4 dimensions:

Each quadrant of the coordinate system represents a dimension. There can of course be more than 4, but often 4 are enough, and to depict more is hard. Please note, I´m very conciously talking about dimensions and not layers. And I don´t want to depict the dimensions as some kind of layers, although it would become much easier to draw them. Layers are fraught with different meanings and suggest different levels of abstractions or certain dependencies.

But there is no particular pre-defined dependency between the dimensions and the holons can be on different levels of abstraction with regard to their dimension. They just are holons of the same kind and on the same level and are parts of a holon at the next higher level of the holarchy.

The n-dimensional space of a holon always has at least 1 dimension: the Problem Domain dimension. That´s the dimensionall the code belongs to, that directly contributes to the solution of the user's problem. If the user´s problem is "write and print an invoice", then a Method to calculate the sum of the invoice goes here, or a Type to represent an Invoice belongs into that dimension. But a Method to serialize an Invoice instance does not belong there.

In addition to the Problem Domain dimension, there can be an arbitrary number of Infrastructure dimensions, each representing a concern separate from the Problem Domain. Take security for example: If you decide to protect invoices with a password and encrypt them, then all the holons concerned with this belong to the security dimension. The reason is simple: "writing and printing an invoice" would work perfectly well without encrypting the invoice. Of course that doesn´t mean, security is of lower value! It just means, it is an orthogonal concern with respect to the Problem Domain.

Dimensions are not about priority or importance! They are a way to structure your code and find the "right box" to put it in. If software layers suggest to put frontend and businesslogic and data access in different entites (e.g. classes, libraries), then Software Cells suggest to implement different concerns in different holons.

The message of Software Cells is:

Always be aware on which level of the holarchy you´re thinking.

Always be aware of the dimension of the holarchy you´re thinking in.

My feeling is, that much misunderstanding in communicating about software architecture stems from not being clear what you´re talking about in terms of level and dimension. Also, when you´re not minding the dimensions you´re neglecting a chance to modularize your software along very natural lines.

The following picture hopefully shows, how multiple dimensions help to modularize a Solution without leaving out any concern and at the same time always keep your picture focused and clean:

Two Applications (on the vertical dimension) communicate with each other. They belong to the Problem Domain. The view is focused on whatever is necessary to solve the user´s problem. From that perspective, the communication between the Applications is direct.

In reality, though, the communication is mediated by another Application on the Infrastructure dimension. That Application also has some Core logic of its own kind, maybe some routing algorithm specific to the problem to solve - but which does not belong to the Problem Domain.

All three Applications are crucial to the whole Solution, so you want to be able to view how they interplay. But at other times you want to focus on one or the other concern of your solution and leave out unnecessay details. That´s where the dimensions literally enter the picture. They allow you to concentrate on certain aspects of a project without loosing sight of the whole. (Aspect Oriented Programming (AOP) might be a help to map the conceptual dimensions to code.)

You can use the n-dimensional Software Cell space like a cube and rotate it any way you want. Each surface representing a dimension. Whatever surface you´re looking at is your focus at the moment and you can assume all artifcats on other surfaces as given. There existence is transparent to you. Thus you always have an uncluttered picture of your system at a level of abstraction you desire.

I hope, the now again expanded Software Cells model helps you, to structure your software better while exploiting all the technological options available.