What is Software Architecture

Lets starts with an example of what software architecture is with an excerpt from Luke Hohmann in Beyond Software Architecture: Creating and Sustaining Winning Solutions:

“Software architecture is the sum of the nontrivial modules, processes, and data of the system, their structure and exact relationships to each other, how they can be and are expected to be extended and modified, and on which technologies they depend, from which one can deduce the exact capabilities and  flexibilities of the system and from which one can form a plan for the implementation or modification of the system”

With this understanding, we know that software architecture is much more than just how the software that you’re developing is structured. There are also implications on how the software can be maintained and expanded on when new functionality is requested. Understanding when changes are needed and how they can be implemented without causing errors in other parts of software.

Software architecture encompasses a wide range of challenges and things to think about when developing a new architecture. I would like to focus in on a structure that I have found to be very beneficial when developing software for embedded systems. Also some of the structures I have found to be detrimental when developing software for embedded systems.

The first embedded system structure I found to be detrimental to software development had the following issues:

  1. Accessing hardware registers each time data from that input was needed.
  2. Software was too specific to each product line it was used for.

The issue with directly accessing the hardware register each time it was needed is that the value could change each time the register was accessed. This change could be due to signal noise or interference of an external source for the input. The issues with having specific code is that there is very little reuse between products that may function similarly. Reuse is a time saver for those implementing the software while also improving the reliability of the software that is developed. Without reuse there is added complexity on if you are trying to move the software from one controller to another of a different type of controller.

The second embedded system structure I found to be detrimental to software development had the following issues:

  1. Implementation of an advance programming concept that was not intuitive to the developer.
  2. Unnecessary complexity due to the advance programming concept.

The issue with implementing an advanced programming concept is, the implementation must be well defined and supported with documentation describing what was implemented. Due to the lack of documentation and support from the previous developers, this caused a delay in implementation of any new functionality without prior experience with the software. The issue with using an advance programming concept in a language that did not natively support this concept, more work than necessary was put into developing software that would conform to the existing implementation. Specifically most of the handling of data was through structures of function pointers. If a new feature was to be developed, extra time was needed to understand how the data was being passed from feature to feature and to validate the implementation is not cause errors in other parts of the software.

The embedded system structure that I found to be beneficial for maintaining and adding new functionality is a “3 Box System” please reference the figure below.

Figure A: 3 Box System

The first box encapsulates all of the inputs need for the software application and evaluates them once. This encapsulation allows the rest of the application to know that the data will not change when making decisions later on. This data is then passed to software application in the form of a structure of parameters.

The second box encapsulates the software application while using the input data structure of parameters and passing the outputs of the software in a structure of parameters. Due to the possible dependencies between different software applications this calculated data will be saved in a structure of parameters. These calculated parameters can either be used as inputs to other software applications or used in the last box for controlling the software outputs.

The third box encapsulates all of the outputs the software application was meant to control based off the gathered input parameters or the calculated data parameters. These software application outputs could range from turning an output driver on or off or updating a value used in a CAN message to communicate any number different data values. This also includes any number of other useful information to the user or rest of the machine in a multi-controller environment.

One of the benefits with this structure implementation is that the software application encapsulation could be replaced with generated source code from an external tool. This source code could come from models in MATLAB and Simulink or another environment that generates a software application. Also this allows for more developers to use model in the loop testing in the case of using MATLAB and Simulink or another test environment to verify their application before needing hardware to validate the developed software. Which reduces the dependency on hardware when prototyping a new feature.

In conclusion we learned about what software architecture is and how having a good software architecture can reduce some of the issues that have been discussed above. Also discussed what a good software architecture can do in terms of maintainability and reliability for the years to come.

If you have any questions about software architecture or need help reviewing your current architecture for maintainability, sustainability please do not hesitate to contact DISTek Integration, Inc.





Featured DISTek Expert




Software Engineer / Project Manager

Technical Strengths:

Embedded Systems, C, Ada, Perl, CAN, ISOBUS 11783, SAE J1939

Past Experience

Embedded software development in avionics industry. Driver development & maintenance for custom embedded operating system in the Off-Highway industry. Technical lead for ISO 11783-6, 10, 13, & 14.

DISTek Employee Since:


What I love about my job:

I love working for a small business that invests in me & my family and where everyone takes care of each other. I'm thankful to have the opportunity to work with amazing engineers who are always willing to lend a helping hand & mentorship. I've grown to really appreciate that the solutions we work on, while not always hip & trendy, are the solutions to difficult tasks and our expertise & ability to problem solve is something to be admired.

Click HERE to become a DISTek EXPERT!