What is Software Architecture?
Software architecture is the analysis, thought and design considerations that form the foundational scaffolding for a successful software system. If you write software for work or as a hobby, whether you know it or not, you’re already dealing with software architecture and the processes of making architectural decisions within your applications. You might even work for a company where software architecture is a defined, hired-for skill set with its own career development track.
Every software system inherently has some form of architecture backing it; this is true from the smallest one-line program to the largest software systems in existence. Smaller applications can usually get away with implicit, undocumented architectural decisions, as these programs are often built using off-the-shelf technology components that already mandate certain well-proven architectural patterns. The more complex the system, however, the more likely it is that its architecture needs to be explicitly defined, so that the various decisions and tradeoffs that go into its architectural makeup are made clear to all interested parties. This is especially relevant for documenting how those decisions impact the end users of the system – ideally in a positive way!
If the concept of software architecture is still not clear – think of it within an analogy of physical architecture, engineering and construction. If you fancy yourself as a DIY-er, you may be able to build yourself a shed fairly easily. You implicitly know that you’ll need a few walls in order to support a roof – you wouldn’t want to let the rain in. Chances are you can purchase some pre-made wall and ceiling frames, some extra planks of wood – the remaining work required is then just nailing everything together in the correct configuration. Now, think of what you would do if you wanted to build a skyscraper…
Is building a shed in any way similar to building a skyscraper? Yes, in that they both exist within the same physical forces and adhere to similar restrictions those forces impose. No, in that building a skyscraper is a far more complex undertaking if you want it to stay standing for any length of time and for it to be safely habitable for a large number of people. You wouldn’t want to construct a skyscraper without having a clear architectural design to follow.
Similarly in software; systems intended to meet critical safety and availability requirements, or those that will be used by millions of users and require immense scalability, all need well-defined architecture if they are ever to meet their goals.
A software architect is a designer, planner, and often a builder too.
What Goes Into Architecting Software?
At its core, software architecture is about finding a balance between conflicting forces in an imperfect, ever-changing playing field. No easy feat! There is rarely one correct way of doing things, and choosing a way forward often involves compromising on certain areas to the benefit of others.
Software architects need to appreciate needs and requirements from a wide range of stakeholders, all with vested interest in their own definitions of ‘success’ for the software system. All these inputs are needed so that an acceptable balance can be found, and so any trade-offs can get made as objectively as possible.
The primary elements here are the needs of the end users for which the system is getting designed, but these are by no means the only set of requirements. Profit and loss projections, with associated investment or budget constraints; infrastructure limitations; data flows, interactions, residency, and security of that information are all key factors, as well as anticipated usage/load projections for scalability, available skillsets of the delivery teams, external integration touchpoints, additional corporate technology policies, and the list goes on.
Software architects need to engage with all stakeholders and catalogue the decisions that have gone into designing a system, along with the assumptions under which those decisions were made. When requirements change in a way that invalidates assumptions, stakeholders need to be kept up to date so that new compromises based on fresh assumptions can be reached.
A software architect is an analyst and a negotiator.
When is Software Architecture Defined?
Unlike physical engineering, software can evolve much more rapidly and even pivot direction entirely – the cost impact of these changes is usually far lower. Deleting a codebase is much simpler than tearing down a partially-constructed building, although sunken labor costs are a common factor. Software architecture needs to keep up accordingly.
It is valuable to define some broad-brush architectural decisions upfront – such as what the central technology stack will be that can best meet the anticipated needs – but the architecture of a system needs to evolve over time, adapting to meet ever-changing requirements. For large decisions with multiple outcomes, an architect may be required to prove out the viability of certain concepts ahead of time, to help minimize any wasted engineering time and cost in pursuing a suboptimal or even invalid path. The majority of software architecture takes place during this time – leading up to and continuously throughout the engineering or the coding of a system.
Some software architectural changes may be brought in at a later date in a system’s lifespan, once it has been live for a number of years. These can be done to modernize the system so that it remains maintainable and extensible with current technology components, patterns, and skill sets.
There are, of course, limits to this – some systems are too critical in day-to-day operations for them to get updated without significant risk mitigation, or there may be insufficient resources available to justify upgrades. These systems may continue to be maintained using the technology and architecture of their time (likely done by expensive contractors out of an ever-dwindling pool of developers that are still proficient with the old approach). Such systems may even get rewritten entirely with a modern stack if they still provide long-term value, including processes for migrating users over to the new system. Or such systems might get sunsetted entirely if there is no remaining justifiable value.
A software architect is an empiricist and a custodian.
Why Do I Need Software Architecture?
Reading all the above, you may be thinking, ‘There’s a lot to consider here… Do I really need to go through all this? Can’t I just start writing code?’.
And the short answer is yes, there’s nothing stopping you from writing code. Just do so with appreciation of the potential downsides – the cost of not considering things.
Lack of planning often results in needless wasted iterations, rewrites, delays, and lost windows of opportunity. There are also ‘positive downsides’ – if your system ends up more successful than you anticipated, and your current architecture can’t meet your burgeoning scalability needs.
Similar to physical architecture, there are a few central patterns in software architecture that are proven over time and rarely change. More recently, internet-scale systems and associated cloud computing have brought their own batch of these patterns – often evolutions of pre-existing concepts, and many that have brought software and infrastructure closer than ever before. It is therefore rare that brand-new architectural ground is being covered when writing modern software, given this wealth of existing knowledge and the availability of many proven technology components, frameworks and middleware.
Basing a system on existing patterns and components will likely bring you success, although there is still value in understanding the underlying concepts and the tradeoffs they bring. There is no true “free lunch” – knowing when you’re likely to hit any fundamental limitations ahead of time gives you the ability to continuously plot a course to lasting success.
What Can I Do to Improve My Software Architecture?
This post highlights many different aspects of software architecture, but would need to go on for ages to cover everything on this topic. Hopefully some valuable pillars can be distilled out of this to help in the ongoing thought processes that make up this practice.
A key skill every software architect needs is effective prioritization. Appreciate that there is always more to do, so focus on the highest-priority items that will provide the most value. Here, value means both in terms of immediate return, and in the future; avoiding significant costs if major changes are needed down the line.
Don’t lose track of items further down the priority list – as requirements change, so do priorities. Be adaptable. You don’t need a definitive answer to everything up-front, but ensure that all facets are being considered to some degree.
Prove out concepts ahead of time when dealing with contentious ideas, requirements or solutions, to objectively find the best way forward. Understand that proven concepts can be invalidated if assumptions significantly change.
Appreciate that software architecture is not unidirectional; the forces involved are ‘softer’ than physical laws, and problems can get solved in more ways than one – it is a constant balancing act.
Iterate; revisit previous decisions once new information comes to light. Renegotiate with key stakeholders if decisions need to fundamentally change so that greater balance can get reached. Renegotiate as early as possible to avoid further waste.
Keep stakeholder communication active. Good lines of communication mean it’s easier to compromise on other areas when specific needs must get addressed. Software architecture should not be an ivory tower concept – treating it as such only creates barriers and reduces communication, which make it much more challenging to achieve success.
Keep up to date with modern patterns and principles, but be able to spot similarities with older ideas. It is rare that a concept is Truly New in software architecture – although many software engineers who have recently entered the profession would like to think otherwise! Good architecture practices are as much about gaining wisdom than anything else.
Design and build things. Ship them to real users. Don’t be afraid to get your hands dirty. Embrace and learn from failure just as much as from success – and don’t be too upset when successes are silent but failures are shouted from the rooftops.
Importantly, find fun in the craft! Software architecture is an amazing, enjoyable, and rewarding experience – especially once you’re able to witness the growth of actual users interacting with the system you’ve helped design and build.
Do you need help improving your software architecture? Contact us to discuss how we can help you improve your approach to architecture or help you architect your next application.
Be sure to check out our Architecture Spotlight series for more in-depth software architecture design patterns – the first entry is on event sourcing, which allows you to record all changes made to an application’s state in the sequence in which they were applied.