BLOG

Architectural Decisions – Soft skills for Software Architects

by Sysco Labs Articles 22 May 2017

In this Innovation Session, Anjana Somathilake, Vice President – Engineering at CAKE LABS, speaks on architectural decisions.

Software Architects are one of the most critical members in a software engineering firm. But why are they so important? Well, architects work with teams and could be the difference between making a product extremely successful, or an utter failure. They play a key role in any project. Everything from team mentoring and guidance, negotiating with stake holders and so much more, are done by architects. Although we can’t go into all the aspects of a Software Architect, let’s look at one of the more important skills an architect must have… decision making, and more specifically – architectural decisions.

So, what is an architectural decision? A quick look at Wikipedia gives us this definition: “Architectural decisions are design decisions that address architecturally significant requirements; they are perceived as hard to make and/or costly to change.”

Below is a diagram that’ll make this definition a little easier to understand:


Architectural Decisions Chart
Now, the complication in this comes when trying to differentiate between a technology decision and an architectural decision. For example, the decision to use Ember.js as your web framework seems to match the criteria given above, but it is in fact a technology decision and not an architectural decision. An architectural decision would be to use a Web based SPA UI for your application.

This kind of decision helps the team to better understand the road the product is going on, and can make technology decisions based on it.

It might still be a bit confusing, but these three questions should help you to differentiate between an architectural decision and a technology decision:

  • Is there an overall system impact of the decision?
  • Is it difficult to implement (look more from a team point of a view rather than a single developer point of view)?
  • Is it a technology decision?

 

If the answer to all three are yes, then it is highly likely that you are looking at a technology decision. But, if the question 1 and 2 are yes, and three is no, it is more often than not, an architectural decision.

However, even when broken down to this level, keep in mind that the differentiation is not always clear cut between the two. For example: you make the decision to use Hibernate as the persistence framework of your existing application which lacks an ORM layer. There are strong arguments on both sides of the aisle on what this decision is. Is it a technology decision or an architectural decision? The use of the word Hibernate puts this answer in a grey area.

Let’s move on to the next issue. You’ve made a major architectural decision. Now what?

What comes next, is where your soft skills will play a major part in. You should justify your decision.  Why is this important? Well, as an architect, you are the guide to your team as well as the product, but most importantly, you are also a lead. If you decide and simply force it on the team, no one will understand why the decision was made, and it’ll keep getting discussed repeatedly, in other words, a Groundhog Day scenario.

 

Let’s take an example:

There is an existing system, which has an internal client, talking to a hub which then goes to a JMS destination, and finally goes into the internal application:


Example 1

A decision is made by the stake holders to federate the hub. Now, this is where things get complicated, and the architect of the team must make a key decision.

The internal client is split to three, External, Internal and B2B. All three of these talks to three separate hubs, which then go through the JMS destination before finally going into the application.

From here, let’s look at two ways the decision could go in. One way, is to have a dedicated broker instance for every hub. One benefit of going with this method is that there will be no single point of failure for the system. Even if one system should fail, the others can keep running.


Example 2

The other way in which we could go down, is to have a centralized broker. A centralized system is much easier to manage than a dedicated broker instance.


Example 3

Either decision has its positives and negatives, but unless the decision is properly justified, there will always be a lot of back and forth, whichever decision you may take.

Documentation of the decision is the next crucial step. Remember, there are a very few architects in a company. The scarcity of architects means that they are often shared amongst various projects, or in some cases, to come onboard to solve an issue or kick start a project and then move on. This is where documentation is key. The teams can keep changing once you leave, hence a reference point for people to go back to is key. In fact, most companies invest heavily in this. From investing in a SOA Decision Modeling Framework, to having a template that must be filled.

Food for thought: If you think good architecture is expensive, try bad architecture.

Leave a Comment