gravity and software adaptability

Hi Kevin,

Indeed, this is quite the introduction you made about the problems with
the standard layered architecture. This discussion was, btw, one of the
most thought provoking I have had during the xpdays (and maybe this
whole year, in fact :-). At a minimum, i.e. even if developers don’t get
anything else from it, the hexagonal architecture suggest a shift of our
mindset about software architecture which is very interesting. At best,
I think it can be quite useful in many cases, which I intend to begin to
explore in my job.

As for the influence of topology on our designs, I believe that, most
like words (Emmanuel Gaillot and I consider “architecture” like a
special word in IT, loaded with many social contextual meanings), the
topology of our diagrams reveals much more than simple and objective
relationships within “modules” or “packages”. By drawing a picture with
plain lines, boxes and arrows, we simplify : we offer an abstract view
from a system. Like a map would do about some aspect of the earth. But
of course, unlike the earth, the system is’nt quite existing yet. So
this schematization is much more than selecting a view : it’s
constraining the view in an abstract manner so that the future system we
create obeys to the constraints.

It maybe so that by litterally /piling/ software blocks we /mean/ to
make these blocks difficult to remove. I infer that from many
discussions I have had with some s/w architects, people who make a
living of designing the “good” architecture for a given software system,
most often at the outset of the construction, following the proverbial
analogy : have your blueprints OK before pouring concrete or else you’ll
waste lots of money. We all know this analogy is quite wrong : software
is flexible, even volatile. But since if it’s so, the s/w architect role
has to be revised. To make it plain, maybe oversimplistic, I tend to
believe that architects piling up blocks on layered design diagrams are
telling us “I want this block to be /unmoveable/. Just like my position”.

As I look to the diagrams, I also try to capture some deconstructed
social meaning in them. The standard layered architecure piled
rectangles make me think of a hierarchy : top levels (where the GUI
always is) shining, visible from an horizon. Levels of ends and goals.
Base level : less visible and less known, unreplaceable basis; level of
means, of work. Compare with the hexagonal architecture : a center,
connecting with multiple, seemingly exchangeable partners. Of course
this is subjective deconstruction of these pictures. Nevertheless, I
think a picture can replace a thousand words, and among these words are
words of social position, I think. And since we put a lot of what we are
in what we do, I suspect that even an “objective” “scientific” job like
s/w engineering contains some of our personal ideology.

Yes, very thought provoking, refreshing view ! Thanks for the
supplementary links, by the way. I already read Alistair’s paper, and I
think I’ll go further with some of the references you give in your blog.

Regards,
Christophe

I think s/w architects make the Layers choice partly consciously (not being aware of anything else, for example, as far as they think about it) and partly subconsciouly, because the knowledge of these layers (how to use them and why) is their job. It’s a kind of self promoting dance which I think is not particular to s/w engineers but to anyone whose job is to deal with complex systems. (For another engineering example, why is it that remote control device (TV and so on) are so complex, while we may think that people just want simple devices ?).

In my opinion, big, complex architectures, especially when designed upfront, (or even as a requirement for the project, like “we want this app to use EJB” written in a call for offer) are part of the self-fulfilling prophecy which we call the tunnel effect :
- big, important projects are risky
- risk implies more studies and barriers and layers
- more studies and layers and barriers make the project bigger

To this simple loop, you have to add the effect of “seriousness” wich affects the tone of your presentation about the solution and the volume of your specs as well. Quantity matters, because it can impress the customers. Paying a lot more for a simpler design is clearly counterintuitive.

Anecdotal evidence I have had of the tunnel effect include :
“we need a maximal authentication policy, even on this little two user app (nonetheless we don’t have any physical security policy around here)”
“we need a database, or else we’ll be doomed when the part list will grow over thousands of parts” (but five years later there are still 100 parts in the system)
“we need to make the currency a parameter, in case our business goes overseas” (which doesn’t happens eventually)

The lock in the tunnel effect is of course the lenght of the feedback loop. The more longer you’ll take to deliver useful software, the more dangerous issues you can figure lurking at the horizon, and in most software shops, shops where blaming rules on every significant relationship, fear leads to preventive consolidation, and more studies, and bloated software.

So yes, I think the Layer architecture is at the same time a true faith, rational scheme for dealing with complexity and modularity issues, and a fearful, emotional gut decision to protect oneself against job loss, be it because of too much complexity (and system failure upon an unexepected condition) or too much simplicity (and the questionning about my position as an architect).

My current goal at the job is to transfer my experience of agility to my coworkers who are in majority software architects, paid for writing studies, specs, and slideshows about the “good” architecture, which of course you have to settle completely at the outset of the project. So I encounter a lot of these tunnel effect regression dances. The danger about it to me is that I get tempted to push back, and fall into the trap of designing oversimplistic schemes in the face of complex problems. But as I usually say, within 3 months I’m better off with an oversimplistic working tested program than with an overcomplex not-yet-working infrastructure…

And yes, I think one can definitely install oneself into dogmatic lazyness, especially when the dogma is enpowered by big scalability issues (e.g. a big bank wants all of their app working with only one vendor’s RDBMS, in order to solve a turnover issue) but then after the golden hammer effect feeds the dogma. And paradoxical things, and self-defeating processes begin to happen.

So yes, the hexagonal architecture is definitely a though provoking question, especially when you think of architecture mainly as communication protocol.

Thank you, I’ve recently been seeking for facts about this subject for ages and yours is the best I have found so far.