:::: MENU ::::

What are the right Architecture decisions?

We all play the role of an Architect at one scale or another.  We may not all have the title “Architect”, but in our daily work we make decisions about the architecture of the system.   We may choose a language or a framework for new development.   We decide which design patterns would be best, and which to avoid.   Someone might consider any of these decisions to be “architectural”.  Some decisions like which version of a library to use, are relatively small, while others such as monolith vs microservices can be huge.  The obvious impact of decisions like these, show the importance that our architecture can hold to the company.

We’re all involved in these decisions but how do we know when we’re making the right choice?  What does “right” mean?  Is the right choice one that worked out in the end?  One where there weren’t too many hurdles in development?   How do we know another decision wouldn’t have resulted fewer problems?   Short answer: we don’t know.    It turns out there are many shades of “right”.

Considering the amount of impact a bad architecture could have on a software company, one would think making the right decisions would be forefront in our concerns.  Lots of companies like to use the word “right” in the context of ethical behavior.  e.g. “do the right thing“, or “do what’s right“.  But we don’t often see “right” being used to mean “correct”, or “not wrong”.

I was able to find one example, with Amazon. Where one of their corporate values is that leaders “are right, a lot”.  As I said earlier, there are many shades of “right”; Ranging from “the best possible decision”, down to “it just barely worked”.   In the context of architecture, what does it mean to be an architect who’s “right a lot”?  Does it mean we didn’t make a decision that could obviously be proven “wrong”?  Or that most of our choices were at least debate-ably successful?  Saying that our decisions were anything but “completely wrong”, sounds like the lowest bar possible.

“Success is a lousy teacher. It seduces smart people into thinking they can’t lose.”

-Bill Gates

Bill really gets down to the heart of the issue.  There’s no feedback loop.  If it worked, then we must have been right.  However, just because something worked, doesn’t necessarily mean it will work again.  Just because something worked, doesn’t mean there wasn’t a better way.  The same applies to architectural decisions.  What do we learn from successful architectural decisions?  The software’s working.  The company’s successful.  We’re not seeing any problems.  We’ve clearly made all the “right” decisions.  Right?

It’s a catch-22.  We can’t know how right a decision will be until we do it.  Once we’ve done it, we won’t go back and try another decision.  But does that mean we’re wasting our time?  Should we just pick something reasonable and get on with it?  Is there a way we can make a more-right decision without knowing the future?  How do we know we’re even adding value as Software Architects?

Uncle Bob has hit the nail on the head here.

“The important decisions that a Software Architect makes are the ones that allow you to NOT make the decisions about the database, and the webserver, and the frameworks.”

-Uncle Bob

Though the article reads as condescending, he’s right. (maybe it’s just my brain adding the condescending voice)  Good architecture is about putting off the “important” decisions.  It’s about honestly embracing that we don’t know the future.   We often won’t know what parts of the system will need to scale, what areas will be bottle-necks, what new hotness will be added to what languages or frameworks.   All we can do now, is try to shield ourselves from the risk, and position ourselves to take advantage of that knowledge (once we have it).

With that all in mind, here’s a list of questions that might point us to a better architecture:

  • How easy would it be to rewrite part of this?
  • Could we utilize a new library or something maybe in a different language later if we needed to?
  • How challenging would it be to switch to a different database technology? to deploy as a command-line tool? to distribute as a library? to deploy to AWS? to create a native-mobile version?
  • What’s the least amount of work we could do today to ensure we keep our options open for tomorrow?

Notice there’s a common thread: responding to change.  If there’s no clearly best-path then good architecture is about making the software more “agile”.  Sometimes the right decision is the one we can put off and still make progress.  Sometimes the right decision is the one we decide not to make.


So, what do you think ?