Software Architecture and Design: Where to Start

Home » Software Architecture and Design » Software Architecture and Design: Where to Start
Photograph of columns in old building

In time one of the main themes of this blog will be about software architecture and design.

There are many different terms used to describe this important subject and sometimes they are used interchangeably. In this blog, “Software Design” will mean the internal design of programs, “Software Architecture” will mean the organisation of, and relationship between, different programs used to make up a system.

So “Software Architecture” refers to the overall system design and “Software Design” refers to the design of objects and components within a program used in the system.

I think this is a very important topic that is not covered that well elsewhere. A lot of example code you see on the web, or books you read about programming, even examples from professional companies that sell third party libraries for example, include anything about architecture or design.

So why is it important?

Well in order to write software you do some kind of design whether you think about it or not, I think its important not to take the default option and not think about it before you start writing code. The time spent writing the system, the efficiency of it and the ease of maintenance are just a few things affected by good architecture and design.

Wikipedia has a good definition of software design, but the things we are interested in are basic architecture and the SOLID principles for design which help you to organise your code in a much better way than the default “Thick Client” way. The idea being that you use object orientated design to organise your code into more but simpler classes that are easier to work with than just having one big page class and throwing everything in there. Managing the dependencies between these different classes, components, objects (call them what you will) is one of the key software design skills.

Diagram showing typical multi layered architecture
There is no right or wrong way to do software architecture and design, but having thought about it, you will at least have a plan and you will avoid the default option of the “Thick Client” approach that I have seen and laboured with so many times in the past for various customers. “Thick Client” is where you just use the “Code Behind” option in Visual Studio and build up an application on a page by page or form by form basis. All the logic, everything goes into the pages, so in the end the system is one unmaintainable morass because all the features of the software are spread across many different places. I worked on a ten year old system that had been developed like this a few years ago, and despite working on this system for months, there were so many interdependencies in this system, it took hours and hours of reading code to understand what was happening before one dared to make a change. This system was slow, unreliable and making changes to this system cost 100’s of times more than what they should have cost, had the system been designed better in the first place and up until my joining the project nothing at all had been done to improve matters. The “Thick Client” approach is only really suitable for prototyping and only then if the prototype is going to be thrown away (not something I do very often – Agile thinking takes a prototype and develops it into a real system, so thick client is most definitely out at any point).

Diagram showing typical layered software architecture
Please note, I am not calling anybody “Thick” here, certainly not my customer. Thick Client refers to the fact that all the code, everything, is in the Client (User Interface) layer. One of the goals of software design is to separate out the business logic (and other components such as data access) from the code that must be there to glue everything together and to make it work – the “Plumbing” for want of a better term. This is a topic that will be explored thoroughly in future posts.

So what’s the alternative to “Thick Client”? How can I fix a system that I come across that is bad in these respects? How should systems be designed? Where can I learn more about it? How do I tell the difference between good and bad if I don’t have experience of the good? Where does Agile fit into all of this? How about TDD (Test Driven Development)?

I will try during the course of this blog to come up with some good posts that answer these questions and more, and also illustrate different aspects of this important subject, with worked examples.

More on SOLID principles

If you haven’t heard of the SOLID principles before, there are many resources on the web. Two I have picked on are the MSDN overview of SOLID principles, and Uncle Bob being interviewed by Scott Hanselman about SOLID principles – this also has a transcript in PDF format if you prefer to read rather than listen (I listen a lot in the car when driving out to see customers). I need to go into a separate post to even start to do SOLID justice (and then there is the question of examples). It does take a while until something suddenly just clicks and then you find you think that way automatically. One final link for now on SOLID is the SOLID post on Stack Exchange.

About Phil

I have been working as a software developer since 1983. This blog could have been called "From Fortran 77, C and Cobol to C# in 20 (not so) easy years", but it doesn't sound quite right somehow. Besides I'm talking about what's happened since 2003, not before!

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Top Posts & Pages


Recent Posts

Recent Comments



  • Mike Cohn's Blog
  • Scott Hanselman's Blog

I’ve been quite adamant lately that story points are about time, specifically effort. But that does

I've been getting more and more emails lately from people confused about the difference between

Transitioning to Scrum is worth it, but some aspects are challenging. 

Recapping our agile podcast’s initial launch series of topics

- Scott Hanselman

I am not a Home Assistant expert, but it's clearly a massive and powerful ecosystem. I've

- Scott Hanselman

I was reading Gabby's blog post about the new TypeScript/JavaScript project experience in Visua

- Scott Hanselman

I've talked about how I love a nice pretty prompt in my Windows Terminal and made videos showin

- Scott Hanselman

I wrote a Tiny Virtual Operating System for a 300-level OS class in C# for college back in 2001 (?)

- Scott Hanselman

If you're excited about Hot Reload like me AND you also want an "A" grade from Securi