Why you need a software architect.

By | July 14, 2018

In the following post I will show why you need a dedicated software architect by drawing some parallels to actual architects from the building industry to show why you need a software architect.

The software developer

Long ago there was a house as in the plan below. The owners of the house wanted to add a feature to their house “entertainment room” where they could place a pool table, darts and entertain some people.

The owners looked at their options and decided it would be the fastest and cheapest to build a big new room next to bathroom and kitchen and use that as the entertainment room. They simple had to add 2 new walls, concrete floor and roof and would thereby make their house bigger and push up the value of the property.


Above is an example of my own house long ago before I bought it.

Click to enlarge

It turned out that the home owners buddy was a builder and had owed them a favor…so the builder hired some bricklayers and set of to build the new room. The builder looked at the job and it was simple enough to do. The owner of the house has given him all the details of the feature they wanted and off he went.

This is similar to the software developer (builder) receiving the instruction directly from the product owner (home owner). The product owner wants a feature added and the software developer is the guy doing exactly what the product owner wants without question.

When the build work was done I am sure they felt very proud as they managed to add an additional room cheaply to their house with minimum effort and even managed to re-use some components. Job well done.

 

Click to enlarge

In the software industry…

At this stage the developer would be praised by the product owner for his fast pace at which he managed to deliver the feature and he is very likely to get a good increase because of it because we managed to ship this feature to the client super fast and at low cost…but who looked at the risk?

And then things went wrong!

What the owners did not realize or did not care about was that they had build over a drain and that all the waste and water pipes for the bathroom and kitchen lied under the floor of the new room and there was now no way to get to it in case of a blockage.

Click to enlarge

The only ventilation of the toilet room have been removed as they could not have a toilet window leading into the entertainment room. The roof also had to be joined which meant that it was very prone to leak in rainy weather… but hey! Feature delivered well done!

In the software industry…

This is often the same in the software industry. The feature is delivered and what no one realizes is that the software developer without knowing managed to break, constrain or impede other features within the system with his ‘quick fix’ solution. These broken, constraint or impeded features could lay undiscovered for months but it will cost the company dearly once identified.

Back to the house…

There I showed up and bought the house… What was there not to like about the house? The house had several large rooms including an entertainment area and a study exactly what I was looking for….lucky for me I went and pulled the building plans and discovered the illegal structure before the transaction went through.

It is at this stage that this nice cheap add-on came back to haunt the owners and now it was a lot more complicated and expensive to fix all these problems.

Who was to blame now? The owners or the builder?

In the software industry…

The same often happens in the software industry. Often the architect is bypassed as he is viewed as unneeded, he just slows things down and adds unneeded complexity… its just a simple feature… The product owner thus describes the feature that they want and the developer set off to develop it exactly as it was described…

The software architect

The software architect is very similar to the architect from the building industry. He does not build features he is concerned about use cases, requirements and cross cutting concerns. What do I mean?

When you pay an architect to draw your house plans you are not paying him to draw the extra lines on the paper. You are paying him to consider everything required to keep your house safe and within in building regulations.

Once he has considered all the structural requirements, regulations and infrastructure like plumbing and electricity only then will he look at what you want to do in the room and if that has any impact. The plan is of no real value to you as home owner, you value it so little that you don’t even store or look after it yourself.

If the home owners consulted an architect he would have saved them lots by pointing out the problems with their decisions.

Click to enlarge

The software architect is trained to look at different things than developers. It is wrong to consider the value to be in the artifact / document that the architect produces. The value lies in the items being considered. 

Software architects are not primarily concerned with the feature that the product owner wants to add and many people don’t understand this. Our job is to consider all the hidden aspects of software application and how the new use case (what the user want to do) will impact the system and other use cases and what would need to be done to delivery the workable feature in the end.

The architect will not just do what the product owner wants. He will come back with possibly multiple solutions that is correct for the system to maintain its integrity.

Like in the example below it would have been a possibility to break the wall between the lounge and the study to create an entertainment room that could also be used as a study.


Click to enlarge

In my situation the owners where forced to fix their problem because their feature broke the existing architecture and infrastructure. They had to close off the drain, re-reroute all the waste pipes, add a ventilation fan and replace all the tiles in the room as a result.
Click to enlarge

The same is often encountered in the software development world where software has to be re-factored or re-organized at great expense of the company.

In my next article I will look at agility. How can one remain agile while maintaining integrity.

Special thanks.

I got the following idea from a fellow Architect, Janus Liebenberg and decided to build a post using an example of my own.

Please be sure to also read.

Leave a Reply

Your email address will not be published.