Closing a door

Closed door

While following the Tweets that sparked my last post, I read the following regarding software architecture as a set of design decisions:

Yes, these decisions shape–give form to–the system. But they also shape–set direction; constrain; bring integrity, consistency and unifying aesthetic to–the system. And, yes, the structure of the system encompasses decisions, so there is at least an overlap between these definitions, but the emphasis is shaded differently

Ruth Malan, A Trace in the Sand, Software Architecture Journal (1/13/2011 entry)

The second sentence, particularly the word “constrain”, stood out to me. Architecturally significant decisions, while setting the path for an application’s evolution, can also eliminate alternate paths from consideration. Our decisions frequently close doors, some of which may be extremely difficult to re-open.

Later in her blog entry, Ruth notes that architecture expresses intent: “what” (functional requirements) and “how well” (quality of service requirements). In her words, “…the form should deliver and serve the system function(s) or capabilities, and it should be sustainable (so evolvable and, as pertinent, scalable, and so forth)”. She cautions, however that “…there will also be choices that are so subtle we didn’t even know we were making them”. This is particularly important, because “…deciding that something is architecturally significant means it is one more thing the architect (or architecture team) is going to need advocate and explain and defend and influence and coach and tend…nurturing and evolving the design in the context of organization needs, forces, personalities and more”. This applies to unconscious, unintended decisions as much as those that are made deliberately.

There is a common thread that runs through this post, “It worked in my head”, and “The Most Important Question”: care. Exercising due diligence to provide a sustainable architecture is the hallmark of an effective architect. Painting yourself into a corner when you had alternatives is the unforgivable sin.

In “What’s driving your architecture”, I cataloged a dozen different factors that drive architectural choices. The complexity inherent in considering and balancing these factors is a prime reason that I have no confidence in the concept of emergent architecture. It is difficult enough to evolve and maintain a cohesive, sustainable architecture of any real size when working with an architect/architecture team with a well articulated vision. To suggest that it will “just happen” as a result of individuals doing the “simplest thing that could possibly work” seems a bit Panglossian. As Charlie Alfred noted in a comment on “The Most Important Question”: “Decomposing a system into its parts can only tell you how they work together, but never why they work that way”. Without some unitary guidance, it’s unlikely that the “why” for the system as whole was actually adequately considered.

Another potential source of inadequate decision-making is deferring decisions for too long. Rebecca Wirfs-Brock, in “Agile Architecture Myths #2 Architecture Decisions Should Be Made At the Last Responsible Moment” made the case for just enough up front design thusly:

So what is it about forcing decision-making to be just-in-time at the last responsible moment that bugs me, the notorious non-planner? Well, one thing I’ve observed on complex projects is that it takes time to disseminate decisions. And decisions that initially appear to be localized (and not to impact others who are working in other areas) can and frequently do have ripple affects outside their initially perceived sphere of influence. And, sometimes, in the thick of development, it can be hard to consciously make any decisions whatsoever. How I’ve coded up something for one story may inadvertently dictate the preferred style for implementing future stories, even though it turns out to be wrongheaded. The last responsible moment mindset can at times lull me (erroneously) into thinking that I’ll always have time to change my mind if I need to.

Making decisions early that are going to have huge implications isn’t bad or always wasteful. Just be sure they are vetted and revisited if need be. Deferring decisions until you know more is OK, too. Just don’t dawdle or keep changing your mind. And don’t just make decisions only to eliminate alternatives, but make them to keep others from being delayed or bogged down waiting for you to get your act together. Remember you are collaborating with others. Delaying decisions may put others in a bind.

In a follow-up post, she buttresses this with scientific evidence from a study that found “…those who were exposed to stress of any kind tended to offer solutions before they considered all available alternatives”. This does not mean that the decisions made were automatically “bad”. However, neither would it follow that the decision made was optimal for the given context. Lots of “good enough” decisions can add up to failure if they do not cohere over the long term and are not revisited.

Care must also be taken not to rely too much on the ability to revisit and refactor. Rework to address changing circumstances and unforeseen issues is a necessary evil from the customer’s viewpoint. Rework that could have been avoided, however, is rightly seen as waste. A little extra work to ensure future flexibility can be easier justified than major revisions to accommodate something you should have known was on the horizon.

16 thoughts on “Closing a door

  1. In many definitions of Software Architecture, the concepts of Architecture are mixed with the “PROCESS of arriving at Architecture”. The fact that “software” does not have any “spatial” attributes is NOT clear in the definition. As a result there is NO satisfactory definition of “software architecture”

    I have a proposal, which I wish to discuss with those interested.


  2. Yes, actually there is this myth when someone migrates from waterfall model to agile. The myth is misinterpreting the ‘evolutionary design’ with the concept of piece-meal approach and “consciously” planning for refactoring. A certain level of thought-work has to be done and good-enough design to be made before you start writing the code.

    Otherwise, for a decently complex problem, it would become highly unmanageable to handle the design as you evolve. You will hit these crossroads where you don’t know whether you are solving something in “problem space (business logic)” or “program (program logic)”.

    Do the refactoring, when it needs to be and when it demands BUT don’s consciously plan or leave it to refactoring.


    • Absolutely…any technique can be abused. Refactoring shouldn’t be used as a crutch. Doing so will lead to customer push back as they get tired of paying for the same feature over and over when they shouldn’t have had to.


  3. Pingback: Fightin’ Words « Form Follows Function

  4. Pingback: Bumper Sticker Philosophy | Form Follows Function

  5. Pingback: Commitment | Form Follows Function

  6. Pingback: Legacy Systems – Constraints, Conflicts, and Customers | Form Follows Function

  7. Pingback: Architecture – Finding Simple Solutions Over a Lifetime of Problems | Form Follows Function

  8. Pingback: What do we mean by “architecture”? | Form Follows Function

  9. Pingback: Design Follies – ‘It’s all about the technology’ | Form Follows Function

  10. Pingback: Bumper Sticker Philosophy | Iasa Global

  11. Pingback: Legacy Systems – Constraints, Conflicts, and Customers | Iasa Global

  12. Pingback: Microservices, SOA, and EITA: Where To Draw the Line? Why to Draw the Line? | Form Follows Function

  13. Pingback: Microservices, SOA, and EITA: Where To Draw the Line? Why to Draw the Line? | IasaGlobal

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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.