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

Categories

Recent Posts

Recent Comments

Archives

Blogroll

  • Mike Cohn's Blog
  • Scott Hanselman's Blog
- mike@mountaingoatsoftware.com

Succeeding with agile isn’t just about knowing where to start, it’s about knowing where to go next—w [...]

- mike@mountaingoatsoftware.com

Here’s what to do when facing a complex user story that cannot be split but is too large for one spr [...]

- mike@mountaingoatsoftware.com

A lot of organizations claim to be agile. Here’s a quick way to see if they really are. [...]

- mike@mountaingoatsoftware.com

Traditionally managed projects begin with a kickoff meeting. Here’s why and how agile projects can d [...]

- mike@mountaingoatsoftware.com

Scrum teams know they need to be potentially releasable at the end of the sprint. But do they know e [...]

- Scott Hanselman

I love dashboards. I love Raspberry Pis (tiny $35 computers the size of a set of playing cards). And [...]

- Scott Hanselman

Blazor quietly marches on. In case you haven't heard (I've blogged about Blazor before) it [...]

- Scott Hanselman

I've posted several times on the Windows Subsystem for Linux that allows you to run Linux on Wi [...]

- Scott Hanselman

Folks have been trying to fix supercharge the console/command line on Windows since Day One. There [...]

- Scott Hanselman

I've recently returned from a month in South Africa and I was looking to unwind while the jetla [...]

Meta