Clinical diagnostic laboratories must have high-quality software in order to run reliably and efficiently. But quality is about more than just the software code. Quality must also be the foundation of the software architecture.
When labs prioritize the quality of their software and software architecture, ensuring it’s built thoughtfully from the ground up, the quality and maintainability of their processes and operations will automatically benefit as a result. But what exactly makes good software architecture?
Well-defined software architecture
Software needs to be carefully planned and designed before development begins. Just as you wouldn’t start building a house or a high-rise office block without architectural blueprints, you shouldn’t build software without clearly documented requirements or before a software architect has mapped the software design.
Software with a robust architecture:
- Enables users. It meets or exceeds end-user requirements and expectations.
- Is maintainable. It does more than meet your team’s immediate needs. It is built in such a way that it can be extended with new features, adjusted for evolving requirements, or scaled for higher testing volume.
- Is auditable. It is possible to determine how every result produced by the system was achieved. A complete audit trail is produced for every action, whether performed by a user, an external system, or an instrument.
- Uses an appropriate programming language and framework. Different languages and frameworks suit different purposes, so it’s important to identify which will work best in your context.
- Balances modernization and new technologies with tried-and-true, stable systems. Before you begin, it’s important to evaluate your organization’s level of risk tolerance and software development capacity. You’ll want to choose the best tools for the project based on these factors.
- Is testable. Far too often, making changes to a piece of code can break other parts of seemingly unrelated code. Software with high testability allows breakages to be detected much easier when running tests so that they can be fixed.
- Is well-documented. This doesn’t necessarily mean you need to keep pages of documentation and diagrams describing the software code. But at the very least, having well-commented source code will ensure that any developers that are new to the software or have spent some time away from it can ramp up on a large codebase very quickly.
How to ensure your software has good architecture
We recommend using an experienced software team with domain expertise in your area. In our experience, a good team usually:
- Includes a software architect, software developers, quality assurance engineers, and project managers.
- Places a priority on quality, is technically competent, and uses best practices (hard skills).
- Is good at communicating well within the team and with your stakeholders and has good time and expectation management (soft skills).
- Is able to develop a shared understanding of the whole system and explain it in a way that is accessible to various stakeholders.
An experienced software architect will be able to choose the right languages and frameworks to use for the project. In the clinical lab space, it’s also really helpful to work with a field application scientist who can serve as an intermediary between stakeholders and the software team to help translate lab requirements into software requirements. This can minimize the confusion that might occur between groups with different professional backgrounds.
During a software project, we recommend iterating and refining the architecture as you go. Even with a solid plan in place, during the building (development) phase of the software development life cycle, software is rarely a perfect match for requirements on the first release. Using an appropriate project management methodology such as Agile+Scrum will help the team manage expectations and changes, building in improvements with each iteration.
Higher quality leads to increased confidence & lower costs
Nailing down good software architecture is critical in the first few phases of software development if you want to see benefits down the line. If the architecture isn’t robust, you might find the software is difficult to maintain, update, or change — all things we know are coming that could cost significantly more to remedy later.
At Semaphore, our software architects and development team work with the lab during the discovery phase to determine what the users need, what use cases should be addressed, and which languages and frameworks are most suitable. We then present this blueprint to the lab before we begin the software development.
Don’t forget: After the software is designed and built, it needs to be tested. We’ll be taking a closer look at testing in our next post.
Contact us if you have any questions about the architecture of your software or read the other posts in this series.
