Why do we have software architects? What is the job and responsibility of a software architect? Why do we do software architecture? What do software architects do?
Fundamentally, software architects have ONE JOB. What is that?
It’s a simple question with a simple answer, but let’s start by asking an even simpler question:
Why do we write software?
Software engineers write software for one reason and one reason only. There is really only one reason any of us get out of bed every morning and go to work — because we get paid. So put very simply, software engineers write software because they get paid to write software.
The corollary of which is software costs money to write. If you didn’t have to pay your software engineers to write software, then software would not cost money, but then if you didn’t pay your software engineers then they would not work and so you wouldn’t have any software.
So why do we have software architects?
Let’s say that I’m the owner of a software company. A client comes to me and asks “can you write me some software?”. Let’s say they have a simple specification, I have a software team that can do that, I know that it’s within their capability. The client offers $100K for me and my team to write that software. I then ask the team lead “how much will it cost for you and your team to write this software?”. After a bit of thinking, the team lead comes back to me and says “we can write this software for $80K”.
So far, this is all good. I know that I can charge the customer $100K for something that will cost me $80K. I will make a profit.
Next, I hire a software architect. The software architect draws some lines and boxes in a UML diagram or other architecture diagram and says “follow this architecture to write your software”. The architecture costs me $5K. Next I ask the architect “how much will it cost me to write the software if we follow this architecture?”. The answer comes back from the architect “oh, about $80K”.
Sorry Mr or Ms. Software Architect:
YOU HAD ONE JOB and you failed
So the answer comes down to this: The ONE JOB of a software architect is to save money. That savings can come in the form of faster up front development costs, reduced maintenance costs, reduced bug fixing time and reduced outages caused by software bugs. However if you’re just drawing lines and boxes on a diagram, or “intellectual froth” as I have heard it called, then you are NOT DOING YOUR JOB.
So the first task that I have to assign every software architect as they come to their job is this: Stop. Step back a bit. Consider what you are doing. Will this improve developer efficiency? Will it help develop the software faster? Will it reduce bugs, or reduce bug fixing time? How does this help save time and money?
Some common faults that I see in software architecture:
- Insufficient documentation — not understood by the engineering team. If the engineering team can’t understand your diagrams, then those diagrams are of no use because they do not save the team time and they do not save me any money.
- Over-complex architecture. Is the time and effort you are putting into this architecture too much for the benefit that it will pay back? This is a common fault of ICONIX Framework — it’s a lot of work to do, will it pay any rewards at all?
- Irrelevant or time-wasting architecture. This is a common fault in MVC architecture — as development teams move towards micro-services, they hang on to this outdated full stack architecture which is no longer relevant for what they are trying to develop.
Better Software Architecture
Better software architecture needs to achieve several things, all of which are very simple:
- Be well documented. I always say one thing to anyone writing a document — write the document from the point of view of the reader. In software architecture, your reader is often the software engineering team. Explain your architecture in enough detail so that it can be understood.
- Have a defensible position. What this means is that you need to be able to back up and defend your claims about how your architecture will help the team or the project. Whether you choose micro-services, Domain Driven Design using Domain Modelling, serverless deployment, containerisation, etc, you need to be able to explain and if necessary demonstrate how this will achieve the goal of software architecture.
- Do software architecture, not software design. Too many times I see articles about “software architecture” that involve details like sequence diagrams, class diagrams (including all of the attributes and methods on every object). That’s all too much and isn’t really software architecture, it’s software design, and can be left to the engineering team or the team leads. You wll fall into the trap of making your software architecture too complex, and it will not save costs. An example that I see often is in the C4 Model — the final layer of this model is far too detailed to be architecture.