Software Cells #D: A Big Picture of Software Architecture and: The Network is the Computer

With my previous postings on the holarchy of the Software Cells model, on how software layers fit in, and what to do with infrastructural concerns in place, I guess it´s time for a little wrap-up.

Software Cells seem to be no less than an attempt to find some kind of unified model of software, to fit as much of what you encounter in terms of concepts in your everyday programming life into a single picture. Since I started out with the modest goal of answering just the question "What the heck is an 'application'?" ;-), I´m probably as surprised as you are, how far Software Cells have evolved over the past weeks. From simple triangles arranged like a biological cell structure to the general concept of a holarchy. Wow!

So let´s step back and see, what we have:

First, there are now several ways to arrange software artifacts:

• Artifacts exist on several layers of abstraction starting at the bottom with Methods and going up to Societies as a term for a network of interacting Solutions which consist of the ominous Applications.
• Artifacts exist in several dimensions to separate them according to their different fundamental concerns from one another. A caching Component serves an important purpose in an Application - but can easily get in your way, when you try to design the parts of your Application pertinent to the main problem domain. So why not "fold it away" in its own infrastructure dimension. Its workings are supposed to be transparent to other components anyway.
• Artifacts exist in several logical categories, to simply group them according to arbitrary needs. You want to talk about several components which are related to user interaction? Well, put them into a "Frontend" category. You can even build a hierarchy of such categories. That´s perfectly fine and entails none of the drawbacks of the old software layers model.

Taken together, layers, concerns and categories span a 3D-space:

That means, each software artifact can be located using a tripel like (level, concern, category), e.g. (Application, Proxy, Communication) or (Method, Security, Businesslogic). This helps greatly, I´d say, to avoid misunderstandings. You can always know or communicate, what exactly you´re talking about.

With this in hand, we can also start to locate existing concepts/technologies, e.g.

• Software Layers: A model concerned with categorizing artifacts up to the level of a single Solution.
• OOP: A programming paradigm concerned with holons on the levels from Method to Type.
• COP/CBD: A programming paradigm concerned with Component level holons.
• AOP: A programming paradigm pertaining to connect Concerns on several dimensions on the Type holon level.
• Design Patterns: A dictionary of recurring "arrangements" of holons on the Type level.
• Enterprise Patterns: A dictionary of recurring "arrangements" of holons from Type to Solution level, also concerning communication technologies.
• SOA: An assortment of concepts regarding holons from Application to Society and infrastructural concerns.

However, software artifacts rarely are islands. Rather they need to be connected with each other on all levels of the holarchy. So the Software Cells model allows connections between holons. My previous posting describes this in details. Just let me summarize here:

• Direct connections only run between holons on the same level of abstraction and within the same encompassing holon.
• Connection can be categorized as stack based or stream based, with stream based connections being the only kind between holons from the Application level upwards. Stack based communication is only possible between holons running in the same Application.

With this in hand you again can classify communication lines in any Software Cells diagram:

Connections between holons from Method to Component are (usually) stack based communication lines, that means simple method calls.

Connections between holons on level from Application up to Society are stream based and need to be described in more detail: which communication medium, which API, which data format? Also, stream based connections need to be wrapped by so called Connection Point components to shield any Problem Domain concern logic from their API details. An Adapter Connection Point serves as a facade before an API on the side of a client, a Portal Connection Point opens an Application for connections from other Applications (or a human user).

Since communication between holons fundamentally changes from Component (stack) to Application (stream), Applications are somewhat a focal point of the Software Cell holarchy. (They are even synonymous with "Software Cell".) They (currently) need more attention than other holons. Since the very term "application" has been underspecified or fuzzy for so long they even need a more rigid definition and more finegrained structure. That´s why Software Cells define Applications as follows:

• An Application consist of at least one Component holon (the main Application logic) which runs inside of a so called Host.
• The Host is a standalone executable and offers infrastructure to the Components it´s accomodating. Host can be as simple as a console EXE or as complex as COM+, BizTalk, or SQL Server. Host offer different communication technology options to choose from for the Portals of an Application. If you happen to implement your own Host, be sure to locate it in an infrastructure Concern. However, most of the time you´ll choose an existing Host for your Applications, which then does not need to show up in a Software Cell diagram (neither in the holarchy, nor in an infrastructure dimension).

Othen than this, Software Cells don´t impose any structure on your software. They don´t tell you your need an "User Interface Process" component or a "Business Workflow". They just say, you can connect Applications as easily as Methods or Assemblies. You need to be aware of what you´re doing, so you need to set up Adapters and Portals. That´s it. If your Solutions then consists of one or 10 Applications... it´s up to you. If you want to put "business logic" into some "frontend" Application... that´s perfectly ok. Or use SQL Server as a Host for complicated calculations... just fine, go ahead! From the point of view of  Software Cells those descisions are all about moving holons around in a holarchy. Of course this might entail consequences (e.g. putting a lot of workload into SQL Server makes it harder to scale cheaply), but you don´t need to be feel constrained by some more or less fuzzy prescriptions from some ivory tower.

If then someone comes along an proposes a certain pattern of how to arrange holons into Categories you can follow his advise - or not. Software Cells are agnostic to those fashions. Or even: Software Cells provide a framework for many such patterns or paradigms, and makes it easy to locate them and put them in relation to others.

For example, it´s easy to understand was meant by Scott McNealy's famous "The network is the computer". Consider the holarchy and add hardware as a host to the picture:

Earlier - maybe until 1993? - only holons up to the Application level were known. That means, problems were solved by single Applications on single Computers (large or small). In the picture the little PC images on white Application holons (also showing the Component and Assembly levels) depict this situation. PCs were the hosts/containers for the then top level holons.

But today? Today the holarchy goes up to Societies - and the hosts/containers for them are not single computers anymore, but whole networks of computers:

The problem solving entity is not an Application anymore. The problem solving entities are Societies. And since problem solving entities (programs) are traditionally run on computers, the "new computers" are networks. To say "The network is the computer" is the same as saying "Society holons are the programs of today."

That also underlines how ever more coarse grained software parts have become: we started out with Methods, then Types, then Assemblies (libraries, DLLs), now it´s Applications - and tomorrow whole Solutions will be reusable parts. (Strangely, Components - the holons between Assembly and Applications - have been touted the building blocks of Applications for some years, but never produced a mainstream technology to concisely define them. Assemblies certainly are not Components in the Software Cells sense.)

With the raise of abstraction of holons goes along a trend towards looser coupling. The higher in the holarchy a holon is, the looser the coupling with its peers. Methods need to be very tightly coupled; Applications are supposed to be very loosely coupled. And Solutions as software parts probably need to attain an ever higher degree of decoupling to be reusable.

A means of decoupling is indirection: you don´t directly bind to and communication with your partner, but first have to determine who it actually is. vtables are a common means of indirection on the Method level. IoC/Microkernels do the same for Assemblies/Components. Message queues are a way to reach this kind of independence for Application. And UDDI can be thought of being the equivalent for Solutions, I´d say.

You see, a systematic view of software with a model like Software Cells makes it easy to spot trends and recognize similarities. And for new developments it can be a framework to hook into and connect with existing concepts. But of course, the main purpose of Software Cells is to make it easier for you to architect your next software solution to a customer problem - be it a single Solution holon, a whole Society, or just an Application or Component. A single starting point for software architecture, that´s what Software Cells are trying to be: For that they provide a place for the artifacts you produce (holons), technologies to run them (Hosts), and ways to connect them (connections and Connection Points). And in case your pictures get too cluttered - well, there are Concerns (dimensions) and Categories to help you untangle the mess ;-)