Having a good software architecture is really important if you want to make money. This article tries to simplify the technology into a very short, non technical article that will help non technical business leaders understand what ‘software architecture’ means’ and why it is important to the bottom line.
I was asked by a business recently what the term software architecture really meant. The company had heard a lot about it but did not understand what it was. So I gave them an ‘architecture for dummies’ kind of response and they said they thought it helped them. So, here is the anecdotal , trying not to be technical, response to the question: ‘what is software architecture ?‘
Firstly, software architecture is as important to software solutions as traditional architecture is for buildings. If you don’t architect a building correctly it will look horrible, be hard to build and may very well end up falling down. Software architecture is the same. I thought I’d explain it by walking through one classic software architecture: a layered architecture.
Programs are generally created by writing functions, i.e. “Get Customer”, “Calculate Interest” etc. The idea behind a layered architecture is you separate these functions into layers and mandate that each layer is responsible for one (and only one) major part of the overall program.
The diagram to the side is a classic layered architecture, this one has 5 main sections:
- User interface layer only presents information to user and accepts input (generally, these are web browser or mobile app based interfaces).
- Application, is the main program, i.e. “Run mortgage process”.
- Business objects are high level supporting functions, i.e. “Get customer mortgage history”. These may get re-used in multiple points in an application layer.
- Logical Data is supporting functions i.e. “Get customer addresses”, this will operate correctly no matter where data is physically stored.
- Physical is the low level stuff i.e. “Get customer address from an Oracle database”, things like SQL are normally in this layer.
The communications between the layers is usually carried out behind well defined application programming interfaces (API’s). An API is actually quite simple, is simply defines what inputs a function needs to do it’s job and what the outputs are. For example, ‘Get Customer’ may require the customer ID number and will return their address and balance on account. This means I can change code behind the API without risking the creation of unforeseen errors to all the other parts of the program that use the API.
A layered architecture mandates that you can only call into the layer below. So the UI layer could not make direct oracle calls to the physical layer but would have to go through the application layers.
“So what”, I hear you cry! Well, let’s say you were using an Oracle database but then decided it was too expensive and you wanted to move to MySQL. Well, the only layer you would have to reprogram would be the physical layer. This will reduce risk and cost. If you had not done this your developers would have to modify many layers which would increase cost and increase the chances of introducing a bug.
More importantly, as the API’s themselves may not change, you can radically change the internals of a function (sometimes called refactoring) with little risk of breaking other parts of the program stack. So you might, for example, completely change the rules for calculating a mortgage but the UI, which calls ‘Calculate mortgage’ API, might not need to change at all. This allows companies to develop more agile and maintainable code faster. It also means that new software engineers know where to look for the code that they want to change.
So, is this what most software developers do ?
The Bad News
In my experience, there have been lots of times where developers did not think enough about the architecture of their solution. They were so keen to get on with the programming that they omitted this stage. I think this is because they may have been taught to program and not engineer or sheer time pressure makes them hack up a quick solution.
In addition, the business idea behind the software is often run by non technical entrepreneur’s who just assume that best practice is being observed. Generally, if the development is not being overseen by an experienced architect, it’s not being done.
This creates real problems for the business as it is normal for the software to be changed multiple times as the business pivots. The result is a code base of ‘Spagetti code’ which is hard to maintain, is buggy and slow to respond to the market. Therefore, as a business owner, ensure you have someone architecting the solution before the programmers start hacking away.
I also reckon that it is one of the key areas you should investigate if you intend to acquire a business with custom built software. Find out how the solution was architected and who knows how to develop and debug it.
Maintenance costs and unhappy existing customers, may be the pig in a poke that you could well do without.