Software Architecture Overview
Software Architecture is a key component in developing a long term, successful embedded system device. However, the topic of what is included in software architecture is complex. Let’s take a look at 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.”
Expanding further on Luke Hohmann’s quote, there are implications on how the software can be maintained and expanded upon when new functionality is requested as the product matures: Knowing how the software can be transitioned between different hardware controllers due to reuse of common components or obsolescence of existing hardware, understanding when changes are needed and how they can be implemented without causing errors in other parts of the software or other controllers when the software has been reused across the product lines, and having development plans for the technology that is being used if it changes, goes obsolete or new technologies surface.
With this, we know that software architecture is much more than just how the software is structured. There are many different facets of software architecture that include licensing of available technologies, software development processes, product development, and software architecture development. When there are discussions on software architecture it is important to specify which aspect of software architecture is being discussed.
Software architecture encompasses a wide range of challenges and design criteria as has been discussed above. In my next blog, I will share some software architecture structures that I have found to be detrimental when developing software for embedded systems.
References:
