gravity and software adaptability

stack During my ‘hexagonal architecture’ session at XPday Benelux, the discussion gave me some clues as to why I feel the “standard” layered architecture model is sub-optimal: I realised that I feel as if I’m looking at a picture of a pile of stuff from the side. Contrast this with a hexagonal model of the same system, in which I feel as though I’m looking down on the picture.

Why is this important? And what relationship does it have to being agile?

The answer, I believe, lies in Lakoff‘s theory that metaphor shapes much of our thinking. When I look at any architecture model I subconsciously impose a point of view on the picture, because my mind relates what I see now to previous experiences. A layered model “looks like” a pile of books or building bricks; hexagonaltable a hexagonal model “looks like” an island on a map (another metaphor in itself!) or a table with chairs arranged around it. The choice of metaphor is made deep in my perceptual system, helping me to make sense of anything I see. And once the metaphor has been selected, my mind will then automatically supply it with a whole load of related beliefs, many learned as a baby. Among these are the effects of gravity and mass, together with related implications of downward dependency.

These associations cause me to believe that the things at the bottom of the pile are hard to move or change. Whereas in the hexagonal view I instinctively feel the system’s components are more loosely coupled – perhaps because they are associated only by proximity, and not by gravity.

So because of these deep-seated metaphorical associations, maybe we build less adaptable systems when we think of them in layers…?


8 thoughts on “gravity and software adaptability

  1. 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.


  2. Hi Christophe,
    Do you believe that software architects make a conscious choice to stick with Layers? Or are you suggesting that Layers makes development hard, so Architects are needed more, so they just got lazy and never looked for an alternative?

  3. 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.

  4. Pingback: building space-stations « silk and spinach

  5. Pingback: gravity and metaphors at the MDDA « silk and spinach

  6. Pingback: the “anchor adapter” « silk and spinach

  7. The importance of a form of representation rings a bell for me on the management side. I found Mintzberg’s breathtakingly simple way of representing any organization by 5 parts with associated forces (strategy, middle management, professional core, techo structure, admin) incredibility helpful especially when using it to analyse how separate organizations can (or can fail to) work together.

    The caveat about such representations is they are most helpful when used as part of your “kitbag” of problem solving techniques. Using them as just another tool helps me from becoming slave to a certain way of thinking…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s