Ralf's Sudelbücher

Meine Fachbücherregale haben es einfach nicht mehr gepackt. Als es auch mit zweireihiger Anordnung und Übereinanderlegen nicht mehr ging, musste ich jetzt schweren Herzens aussortieren. Hier eine erste Auswahl der aussortierten Bücher. Angegeben ist der Preis und die Rubrik, wo sie bei Amazon als second hand Titel zu finden sind:

Mathematik für Informatiker I. Finite Mathematik und Methoden, 7,50 EUR (gebraucht)
http://www.amazon.de/exec/obidos/ASIN/3446123652

J2EE kompakt. Enterprise Java - Konzepte und Umfeld, 6,50 EUR (wie neu)
http://www.amazon.de/exec/obidos/ASIN/3827413818

Questioning Extreme Programming (XP Series), 12,95 EUR (wie neu)
http://www.amazon.de/exec/obidos/ASIN/0201844575

Planning Extreme Programming, 19,95 EUR (gebraucht)
http://www.amazon.de/exec/obidos/ASIN/0201710919

Microsoft Windows Server 2003 Terminaldienste einsetzen, 35 EUR (wie neu)
http://www.amazon.de/exec/obidos/ASIN/3860636561

Programming ADO .NET, 29,95 (wie neu)
http://www.amazon.de/exec/obidos/ASIN/0471201871

Professional ADO .NET Programming, 7,50 EUR (gebraucht)
http://www.amazon.de/exec/obidos/ASIN/186100527X

Datenbankprogrammierung mit Visual Basic 6 - Jetzt lerne ich..., 9,95 EUR (wie neu)
http://www.amazon.de/exec/obidos/ASIN/3827255406

Jetzt lerne ich ADO.Net, 9,95 EUR (wie neu)
http://www.amazon.de/exec/obidos/ASIN/3827262291

Würde mich freuen, wenn die Bücher noch einem interessierten Leser zugeführt werden können. Die öffentliche Bücherhalle in Hamburg und Antiquariate sind leider wg. der fachlichen Spezialisierung nicht interessiert. Und so dachte ich mir, vielleicht finden sich ja im deutschsprachigen Raum Lesewillige. Ich bin gespannt.

PS: Dass ich die Bücher aussortiert habe, ist keine Qualitätseinschätzung. (Immerhin ist ja auch ein Titel von mir dabei :-) Ich muss mich nur aus Platzgründen inhaltlich mehr konzentrieren als in der Vergangenheit. D.h. manche Themen (oder Bücher, von denen ich mehrere Exemplare hatte) müssen anderem, wichtigerem weichen.

In the meantime I had the chance to apply the Software Universe as well as Software Cells to customer problems and wrote an article on Software Cells. Also a friend working at BEA used it to simplify his message for their ESB Quicksilver product.

I'm happy to report, Software Universe/Cells lived up to what I expected in term of making software design easier. But I also realized, some refinements to the model are in order.

The first refinement I´d like to introduce is a new holon level for the platform software is build/running on. I call it the Culture holon. A Culture holon consist of all the Application holons running on the same platform within a Solution. "Culture" seems to be an appropriate term for this kind of entity, since a platform like .NET or Java defines a set of rules and technologies for software running on them, like a social culture does for the individuals living in it.

A second change you can see in the above picture is I renamed the Solution level to Product. The word "solution" simply has such a general meaning, it can cause confusion. You need to find solutions to all sorts of problems on all holon levels, so it seems better to not assign the term to a holon level.

So when you develop software for a customer, you develop a Product. Sounds reasonable, doesn´t it :-)

This Product in turn consists of one or many Cultures, i.e. pieces of software running on different platforms, e.g. a WinForms frontend talking to Oracle running on Linux.

Each Culture is made up of one or more Applications, i.e. processes running Hosts as containers for Components.

And here comes the third change to the holarchy: I dropped the Assembly level. Components consist of Types. That´s it. No intermediate Assembly level anymore. Why? Because assemblies are a platform dependent artifact and don´t really add any "value" to the holarchy. If a developer decides to implement a Component as one or more assemblies is a neglectable detail, I´d say.

Components contain Types, they draw a boundary around types solving a specific sub-problem.

So, why are Cultures important? Because they describe another change in communication between holons. In addition to stack based and stream based communication in general there is platform specific and platform independent communication sitting on top of them! Cultures in the holarchy make this explicit - that´s important. Platform independent communication or communication crossing platform boundaries requires different technologies/knowledge than platform specific communication. In addition different platforms offer different technological options, e.g. Hosts.

With Cultures introduced to the Software Universe, you can´t forget to take platforms into account when thinking about software, you can´t forget to make conscious decisions about the contracts visible to software on other platforms. I think, that´s expressiveness a general model for software needs.

Endlich ist es soweit: Uwe Baumann von Microsoft und ich haben unsere langersehnte Bildungsreise in das ferne und bald so nahe Vaubekien angetreten.
Wir wollen für Sie erkunden, was Visual Basic .NET als Programmiersprache zu bieten hat. Was ist anders im Vergleich zu VB6?
Und vor allem: Wie wird VB2005 mit dem .NET Framework 2.0 in Visual Studio 2005 aussehen?

Wenn Sie auch gespannt sind, was Visual Basic .NET so alles kann, wenn Sie heute noch in VB6 entwickeln und sich fragen, ob ein Umstieg lohnen würde, dann kommen Sie doch einfach mit auf unsere Reise.
Oder besser gesagt: Setzen Sie sich auf den Verteiler für unsere Briefe nach Hause aus dem exotischen Vaubekien, in dem Mönche Konsolenprogramme schreiben, die Staatsreligion OOP heißt und der letzte Modeschrei .NET Attribute sind.

Bei www.vaubekien.net können Sie sich für unseren wöchentlichen Newsletter an die Daheimgebliebenen registrieren.

Po bnjesnam tschuwinasth! - wie der Vaubeke hier sagen würde: "Mögen wir uns bald zu einem kühlen Umtrunk während der Mittagshitze am Rande eines Kornfeldes treffen!" oder kurz: Wir freuen uns auf Sie!

dotnetpro.tv Interview zum Thema "O/R Mapping" mit Mirko Matytschak, der sein Tool NDO vorstellt.

Sandbox-Meinungskolumne "Beta ohne Ende" über das zweischneidige Schwert der frühzeitig breit verfügbaren Beta-Versionen neuer Softwareentwicklungstools.

After I did my previous posting on the "Big Picture", I felt qualms as to whether my vision was a little bit too grant. Does the world really need my view on software? Isn´t there already UML covering almost everything you need to know in terms of modelling software? After having slept bad for a couple of nights ;-) the following answer came to me: Yes, trying to stuff everything into just one model is too much. And I´m not trying to replace UML; in fact UML can be used to express my Software Cells´ concepts.

So, how can my "Big Picture" be chopped up into more manageable pieces? I´d say, it´s best to separate the overall framework from concrete advice. Thus from now there are two different models building on one another:

Software Universe

The Software Universe is supposed to be a general framework for thinking about software. It consists of...

• The holarchy of software artifacts from Method up to Society
• An arbittrary number of Concerns to which artifacts can belong and which are orthogonal to each other
• A hiearchy of logical Categories to which each artifact can belong

Also, artifacts communicate with each other and can form a communication network:

Arifacts communicate directly on the same level within the same encompassing holon and through Connection Points if they need to cross boundaries. Connection points define and follow Contracts governing how one holon can use another one. There is no conceptual limit as to how holons can be connected, no hierarchy, no direction. Software is supposed to be able to form arbitrary networks on each level of the holarchy.

That´s all there is to the Software Universe. I guess it´s simple but nevertheless helpful in its generality. It provides a framework for thinking about software, a framework you can hook into your own models - with the only "limitation" being the holarchy with its predefined levels of abstraction which describe "software containers" and map to real world software artifacts:

However, the Software Universe is open and extensible. For example, I´m thinking if it would make sense to introduce a new holon level between Application and Solution called "Culture". A Culture would contain all Applications running on the same platform within a Solution. This level could make sense because it would clearly mark where communication crosses an important boundary. Let me know what you think of this idea, if you like.

Any extensions to the Software Universe, though, would need to fit into the existing scheme or be orthogonal to it. Also they would need to be on the same level of generality and abstraction.

That brings me to...

Software Cells

Software Cells make very concrete statements about how software should look on a certain level of the Software Universe holarchy. Software Cells thus are on a different level of abstraction than the Software Universe. They are an application of the Software Universe concepts and don´t constitute it. That´s why I pulled them from the holarchy etc. and instead set them apart as a model in its own right. Software Cells can be explained without the Software Universe - but it´s easier, I´d say, if Software Cells are based on the Software Universe.

So what do Software Cells talk about? They zoom into the Software Universe and describe how an Application holon should look like:

A Software Cell is an Application and is called a cell because it is assumed, that every Application has a basic structure regardless of the problem domain and often is part of a network of cooperating applications thus forming something like a biological united cell structure:

The most important part of a Software Cell is its Core which contains the main problem solving logic of the application. The Core consists of at least one Component holon which needs to be run by some kind of Host (a standalone executable). If the Core wants to access other Cells or resources or should be steered by a user, Adapter and Portal Components are the means to do that. A Software Cell thus is an Application holon with the following structural elements:

• Core Component
• Any number of Adapter Components to access other Cells or recourses
• Any number of Portal Components to open up for access by other Cells
• A Host providing infrastructure services to the Core and the Connection Point Components (Adapters, Portals)

Software Cells resemble the software layer architectural model in so far as they define software to consist of several parts. But where software layers put thos parts in a strict line from frontend to data access and otherwise be not very concrete, Software Cells are more flexible. Firstly they put logic at a more prominent and more appropriate position in the center. It´s no longer wedged between other concepts which might not even be present in a software. Secondly communication doesn´t distinguish between arbitrarily grouped technology but makes all input/output equal. Thus it´s much easier to describe networks of software. Thirdly Software Cells get rid of fuzzy terms like "business logic" and replace them with very concrete structures with concrete tasks: Adapter/Portals do only what is necessary to bridge the impedance mismatch between a communication API and the level of abstraction of the Core logic. Nothing more. So the logic is defined by "whatever doesn´t have to do with communication" - and thereby gets free to float from one Cell to another in a Solution (network of Cells/Applications). If you want, you then can split whatever is done by the Core logic into several categories. That´s just fine and uses another dimension of the Software Universe. However, the Software Cells model does not (yet) make any statement as to how your Cells or Core logic should be structured. So if you want to carry over anything from the software layer model, feel free. Just stick to the clear definitions of the Connection Points, the Core, and the Host. Compared to the software layer model more code will belong to the Core logic Components than to the business logic layer.

Also be aware that a software layer architecture often will map to several cooperating Software Cells.

UML

Now, finally, what about UML? Do Software Cells duplicate anything UML does? I´d say, no. Although Software Cells come with their own graphical notation (based on the Software Universe), you can depict everything using UML, if you like. Use a UML package diagram for a Software Cell network (aka Solution), use UML components for Core, Adapter, and Portal, if you like. Although I personally find the UML notation too general in many aspects, I don´t see any real reason, you can´t use it.

UML´s notion of component and package are quite abstract. That make UML widely applicable. Software Cells on the other hand try to be very concrete. A Software Universe´ Component is a set of library files (or .NET assemblies) bound together by a certain purpose. A Software Cell is a Software Universe Application, that means it´s a process hosting Components. UML doesn´t know of .NET assemblies and processes. So you maybe could say, Software Cell diagrams can be drawn as instantiations of UML diagrams with certain stereotypes to denote Software Cell structures and connections.

Phew, I feel relieved now :-) Splitting the Software Universe from Software Cells makes easier to understand and work with both. And seeing UML not as a rival, but complementing drawing tool could help to approach developers to take a closer look at the Software Cells concepts. (However, I still find it easier to quickly draw a Software Cell diagram like above than using UML notation. Maybe I´ll try to set up a Domain Specific Language for VS2005 at some point :-)

Ich hatte ganz vergessen es zu erwähnen: Seit einiger Zeit ist auch wieder ein neuer dotnetpro.tv Tipp online:

http://www.dotnetpro.de/community/downloads/dnptvtipp3web.wmv [300 kbps]

Dieses Mal zeigt Vera ihrem Chef, wie einfach man mit einer SQL Select Anweisung durch beliebig große Datenmengen seitenweise blättern kann.

Aber es gibt noch mehr zu sehen! Die dotnetpro hat keine Mühen uns Kosten gescheut, als Dankeschön für die große positive Resonanz auf dotnetpro.tv im Allgemeinen und den dotnetpro.tv Tipp im Speziellen exklusive Autogrammkarten von der Tipp-Hauptdarstellerin Vera unterschreiben zu lassen!

Die Autogrammkarten werden unter allen Interessenten (oder sollte ich sagen "Fans"? ;-) verlost.
Noch ist Zeit, mitzumachen!
Wer sich also noch nicht versucht hat, eine Zierde für seinen Programmiererspind zu ergattern, sollte sich schnell hier anmelden:

http://www.dotnetpro.de/views/view.aspx?id=78b6fa9b-df3f-4712-8a89-f0ac58fc2f63

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 ;-)

Ok, with software layers finally embraced and infrastructure integrated, I can no longer avoid the tricky topic of connections in the Software Cells model. I´d say they are the hardest and maybe the most important part of the picture.

Let me start by going back to the beginning of the Software Cells adventure: What boggled my mind was the question, how to come to a more precises definition of the term "application". And my answer were Software Cells as a combination of some Core logic and connectors (Adapters and Portals) to communicate with the outside world. So what I essentially said was: The process is the Application. But why? Why has this entity been so elusive and underspecified? And why does it again and again step into the foreground when thinking about modern software aka distributed Solutions and services?

It seems, Applications have some kind of prominent position in the Software Universe, as if their level in the holarchy was somehow special:

After some thinking, I guess I know, what makes Applications so special. It´s because the signify the transition from stack based communication to stream based communication:

Communication between holons from Method up to Component are stack based. It´s simple method calls. Within an Application all holons (usually) communicate in that way, because they live in the same address/memory space.

But since the Application is synonymous with a process (Host), communication with other Applications cannot go via the stack. All Applications live in different memory spaces. Communication has to use other means which are (usually) on the lowest levels streams, and data to pass between holons has to be (de-)serialized.

That also means, in essence, all communication is either done via stack between methods - or it is done via streams between applications. Even if you don´t depict it in a Software Cell diagram, be aware of this. Again: Know the level you´re planning on and if you´re talking about intra or inter holon communication (although this only makes a difference when you´re on the Application level).

One reason why MTS/COM+ and later also Web services suffered from less than expected adoption was, that this break in how holons communicate had not been honored. Instead of showing a picture like the above of the grim reality to the developer community and tell it, the communication paradigm necessarily has to change, Microsoft in both cases tried to gloss over the differences. COM+ as well as the early SOAP/HTTP based Web services tried to continue the method call stack based communication into the realm of messages and streams. Had there existed a model like the Software Cells holarchy back in 1996 or 2000, there would have been no misunderstanding. It would have been clear to everybody, that RPC is not really the same as method calls via a stack. It looks the same - but transforming stack frames into messages takes its toll. (Please get me right, I´m not saying nobody new, what was going on ;-) The guys who knew the ins and outs of marshalling where the kings of those days. Unfortunately I didn´t, because I happily lived in my little VB world back in 1996.)

And maybe here also lies the reason why the term "application" so far was so elusive. It´s because an "application" is on the border between stack and stream based communication. Coming from the world of software monoliths developers wanted an "application" to be a process; but coming from the networking world of enterprise programming, there was a force trying to pull "applications" into the stream based communication world beyond monoliths. The misleading term "distributed applications" was born.

With Software Cells, I hope, such kind of pitfalls won´t happen again. Since the take into view not just one underspecified level of software, but a continuum of levels of abstraction, stumbling blocks like a switch in communication paradigm can be foreseen.

Now, what I take away from this lesson is, how important it is to model connections. So let me propose some rules for connecting holons. The basics as defined earlier of course are unchanged. But I´d like to unify the shapes and connection lines.

Rule 1: Only holons on the same level within the same encompassing holon can be connected directly.

(Green connections are correct, red ones are incorrect.)

Connecting a sub-holon to the encompassing holon (its container) very obviously does not make sense. But also connections between holons on different levels and across holon boundaries should not be made in order to always be very clear about the level of abstraction you´re working on.

Rule 2: To connect holons on the same level but in different encompassing holons, you have to define Connection Points.

A Connection Point defines where a connection between sub-holons on the same level crosses the boundary of their container holons.

Connection Points in most cases are empty and just of conceptual or structural value. They make Software Cell diagrams easier to read. Within the realms of stack based or stream based communication, there need not be any functionality assigned to Connection Points. But where communication switsches from stack to stream, at the boundary of Applications, Connection Points need to transform data. That´s also why there have been Adapters and Portals from the start in Software Cells and why they are still needed after introducing Connection Points as the general term:

Rule 3: Connection Points on the rim of an Application have to be classified as either Adapter or Portal.

The distinction between Application Adapter and Resource Adapter is given up. How much work an Adapter/Portal has to do to bridge the gap between the API and problem domain data models depends on the communication medium. I don´t think it´s necessary to officially categorize Adapters/Portals. If you want to do so, feel free.

Likewise the distinction between User Portal and Application Portal is removed. If shoule be clear from a Software Cell diagram what the purpose of a Portal is depending on what kind of client is connecting to it (Application or Human).

Also, as you can see in the pictures here, the triangle as the shape for an Application is given up. At this point I think depicting holons on any level should be done using the same shape (a circle or ellipse). As long as you clearly mark the level of abstraction of a Software Cell diagram, there should be no confusion as to what the holons depicted are: Applications or Methods or Solutions or Assemblies. The old notation...

becomes...

Although triangles are still used for Adapter/Portal, they are Component holons like any other within the Application holon.

I hope you find this notation as much simpler as I do. Changing the pretty unique Application triangles to the ubiquitous circle wasn´t easy for me. But I think the gain is obvious: Easier drawing and more similarity on the different levels.

After I had written my previous posting about the Software Cell dimensions I kinda felt a little bit ashamed for my software layer bashing ;-) So what I now want to try is get back on board all those who left in dismay. Here´s my message for you:

If you like those terms frontend, businesslogic, and data access so much and find them usefull - well, then you can continue to use them with Software Cells.

For example, simply assign the Components of an Application to the logical categories of Frontend etc. That´s perfectly fine. You can do that even accross holons and on any level of the holarchy, if you like:

This way the value of software layers is retained: a way to categorize code to solve the customer´s problem. But at the same time, the limitations of software layers are avoided: you´re no longer limited by a stack of layers where the world has moved on from stacks to networks of entities.

The strict order of software layers as well as their limited granularity has outlived itself. But the main message does not need to die but can live on in Software Cells: Mind what your code is about! Is it about frontend oriented stuff? Or is it just logic? You name it - no, better, you categorize it. Put it in a logical category like in the picture above. I´d even say: invent any number of them as you like. If it helps you to structure your problem´s solution, it´s all fine.

Just beware of mixing up logical categories with dimensions. A category is a group of holons within (!) a dimension. A dimension is another type of "category" (or space) for holons, whose functionality is orthogonal to other dimension´s holons.

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.