Welcome to part two of my blog series on software architecture. The previous blog focused on an overview of software architecture in general. Part three will focus on software architecture that I have found to be beneficial. For now, let’s review four common software architecture pitfalls that I have encountered:
● Including too much information at a high level
● Focusing on function and not functionality
● Scope creep
● Focusing too much on new technologies
Including too much information at a high level: When reviewing a software architecture with stakeholders and software developers, there needs to be a clear understanding of what the system will do. However, if all of that information is presented in one diagram, trying to understand what the system is meant to do is nearly impossible. What should be done instead is create a simple overview of the system at a high level and then add the various components and functionality under the high level design.
Focusing on function and not functionality: When a software developer works on a feature, they want to make sure that the function works as expected. This is good, however, there is another side of that equation. If the software does not execute reliably due to insufficient memory allocations or an inconsistent execution rate of the software, it will not matter if the software is logically correct. To fix this, the generated software must fit within memory allocations and meet overall execution time constraints.
Scope creep: When talking about scope creep it is easy to think that it can’t happen to your project. However, as more people review the architecture there are more chances for new features or functionalities to be added to the system. If all of the new features and functionalities are included in the initial release this adds extra time to develop the features and testing time that may not have been accounted for when initially scheduling the project. With this instance, it would be beneficial to discuss which features are needed for a Proof of Concept or a Minimum Viable Product before adding more complexity and functionality
Focusing too much on new technologies: As new technologies surface it may be tempting to use them in a key part of the software architecture when prototyping the system. However, understanding how using this new technology will work when implementing the rest of the system needs to be considered. If the technology is too immature in the development cycle or too sophisticated where prototype hardware is not available or too expensive, this can mean doom for your product. While these concerns should not inhibit using new and innovative technologies, they should be approached with caution and allow for integration without impacting the product schedule.
There are other software architecture pitfalls that could be discussed and there are multiple books on software architecture and common pitfalls that a simple Google search will unveil. Stay tuned for my next blog posting which will detail some of the beneficial software architecture that I have discovered.
