How do you define software architecture?

Every software system has an architecture, but not every software architecture is defined. While there is structure to most software systems, sometimes that structure has been explicitly thought about and sometimes it isn't. This is what can make a difference to whether a system works and how it's received by the stakeholders. We have a lot of content on the site about defining software architectures. Here is some of it.

Where do you start?

One of the hardest things about software development is being asked to come up with a design when all you're given is a set of requirements and a blank sheet of paper. Many software teams will dive straight into the code and while this can initially be very productive, the slippery slope of constant refactoring is awaiting those teams that haven't quite found a design that works. Often, a little forethought is all that's needed to get the development process heading in the right direction. So where do you start? Watch the video...

Start with the big picture

One of the hardest things about the software architecture role is being asked to come up with a software architecture when all you're given is a set of requirements and a blank piece of paper. It's certainly one of the most fun parts of the role, but it can be a daunting prospect trying to figure out where to start and what to do. Many software teams dive straight into the code and this can initially be very productive but many teams soon start to venture down the slippery slope of constant refactoring while they try to find a design that works. Often, a little forethought is all that's needed to get the architecture definition process heading in the right direction. Read more...

Software architecture is a platform for conversation

If you're writing software as a part of your day-to-day job, then it's likely that your software isn't going to live in isolation. We tend to feel safe in our little project teams, particularly when everybody knows each other and team spirits are high. We've even built up development processes around helping us communicate better, prioritise better and ultimately deliver better software. However, most software projects are still developed in isolation by teams that are locked away from their users and their operational environments. Read more...

You don't need a UML tool

When tasked with the job of coming up with an architecture and design for a new software system, one of the first questions people ask is about which tool they should use. Such discussions usually focus around the Unified Modeling Language (UML) and whether their organisation has any licenses for some of the more well-known UML tools. Read more...

Defining architecture

• Know your choices - you need to know what the options are, you owe it to your team.
• Options - with so many architectural options, where do you start?
• Technology selection - where do you start?
• What about the application tier?! - sometimes the technology decisions mistakenly shape the architecture.
• Experience should guide, not constrain - you should certainly let your experience guide you in making the right decision, but you shouldn't let it constrain you.
• There's nothing new under the Sun... - why are you building your own frameworks?
• To SQL or not to SQL? - relational databases are established solutions, but there are alternatives.
• How many layers? - architectural layering is good, but use it where appropriate.
• Simplifying deployment - revisiting your deployment model can provide some opportunities for simplification.
• Following the specification - it's okay to break the standards and rules if you know what the trade-offs are.
• Simplicity - sometimes we have a tendency to overcomplicate solutions.
• Conway's Law - your organisation can have a significant effect on your design.

Dealing with non-functional requirements

• Engaging without non-functional requirements - it happens over and over again, but nobody gets what they want.
• The influence of non-functional requirements - never underestimate the influence of non-functional requirements.
• NFRs for system replacements - take some time to revisit what's important.
• Using new technology will make it faster - maybe, maybe not.
• Nines - sometimes you need to challenge the non-functional requirements because they can have some pretty big implications!
• Separating the non-functionals - non-functional requirements are sometimes related, but don't get them confused.
• Scalability Principles - how do you build scalable software systems?
• Architectural Assumptions - your scaling model can affect the code you write.
• Modifying Open Services - how do you deal with versioning open services?

Operational aspects

• The Other Interface - application logging isn't pretty, but ignore it at your peril.
• Adding the fuel gauge - add monitoring to your architecture to get feedback from it.
• Monitoring Java systems - monitoring doesn't have to mean application log files.
• System Design and Reconciliation - neglecting intersystem reconciliation can have some disastrous results!

For more content about defining software architectures, please take a look at our How do you define software architecture? category. See the How do you share software architecture? and How do you deliver software architecture? categories for content related to the outputs of architecture definition.