Software Architects need a combination of skills to be able to succeed and deliver designs that are long lived and able to provide strong commercial value to a business.
Below I list what I consider to be the top 5 skills in order to be a good Software Architect.
#1 Able to listen and confirm what you hear
A lot of what you do in software architecture is what is termed ‘discovery’ – a single word which covers a whole universe of fact finding. You need to work out the why, the when and the how (often with the whom) of the current systems in play and then work out what is actually possible based on the resources available to you. The problem here is that there is usually no one Center of Truth as concerns the systematic state in a business and what you get told is highly dependent on the world view of whom you talk to.
So it is critically important you are able to sift through all the sources of information and derive your own view of how things are put together and the factors in play – hence why the need to listen and the ability to confirm what you hear.
#2 Understand what are hard constraints and what are soft constraints
Hard constraints are the factors you have no control over, it could be as simple as the budget available to something as specialist as certain standards that need to be followed which are mandated by the sector the business operates in – these cannot be ‘traded away’ – they have to be obeyed.
Then there are the ‘soft constraints’ – these are things which impact on or constrain the system design decisions, but if they prove to be painting you into a nasty design corner – you have some wiggle room to ‘trade then away’; or remove a constraint in favor of improving some other characteristic in a system. It might be as simple as picking a new framework or language that the team is not familiar with on the basis that the pain is known to be worth the gain; or it could be choosing to throw away completely a legacy system rather than doing a staged hand over (but be very careful with this).
The goal is to have a clear mental picture of what can be changed as a constraint against what cannot be.
#3 You can do as well as you say
Nothing worse than having someone deciding how systems should be put together and then they are not able to do it themselves. Note: I’m not saying you should, but rather you should have a direct experience with the technologies and frameworks you are designing with – otherwise you risk designing ‘blind’ with little understanding of the practical pros and cons in play. You want to have engineers know that you have that depth of technical understanding so they are free to discuss with you their concerns (and they will have them).
#4 Be aware of all dimensions of dependency
Dependencies between components and subsystems operate on many levels, its not just a simple ‘X calls Y’ relationship. You may find some or all of these additional dependency dimensions in play:
- Only runs in or on shared environment X (i.e a framework or OS);
- Both critically depend on data references to a common third system Y (sort of pass by reference);
- Both actually run on the same hardware (can happen with virtualization a lot) so can compete for resources;
- Both are developed and supported by only the one team (or individual…)
- Part of the functionality of system X is actually running in system Y (bad decomposition).
- Updates to system X depend on updates to system Y (think new functionality) but Y only gets updated once a quarter – you can only develop as fast as your slowest dev cycle.
Once you start thinking about dependencies beyond the pure software dependency use case, you see they actually crop up all over the place.
#5 Security Awareness
In this day and age, with PII, financial data and other sensitive data flowing through all sorts of software systems you cannot really design software architecture without having a strong grounding in security. You need to at least understand the basics of secure software design and be able to weave the concerns of security into your design, so the architecture is naturally secure by design.
It will pay enormous dividends to do this as early as possible in your design process, as retro fitting security onto an existing design is a bit like bolting after burners onto a go cart – you can certainly do it, but you wouldn’t want to be in the driving seat when its fired up!
#6 Know when to be radical and when to be traditional
A bonus! This relates to developing an awareness of when radical change is justified and safe to do and when its more appropriate to play it self and enforce gradual change. The business itself will give you an indication of how much they want to push the envelope, but you need to develop a healthy skepticism of all things new and shiny until they are proven to be reliable and supported for the duration of operation of the systems you are designing. Nothing is worse than picking up a new framework or tech to only have it be shelved not long after you roll out with it – so play safe but keep an eye on new developments.
I hope this top 5 has given you a quick look into what I consider to be the top 5 skills a Software Architect must have in order to succeed at their job today. If you have any questions please feel to get in touch .