Software Architecture (Compliant with IEC 62304)

The software architecture is the description of the internal structure of a software system. Typically, the software architecture identifies the components and describes their interaction and dependency. In this article, you will find information on the following topics: 

  • Regulatory requirements of the software architecture 
  • Teaching materials and checklists 
  • Typical challenges when creating the software architecture 
  • Review of the software architecture 
  • Software architecture during the audit

Requirements of IEC 62304 and FDA on the software architecture 

Typical Mistakes in Creating a Software Development

Mistake #1: No upfront software architecture

My own experience

Twice, I had to learn the hard way how important the software architecture is for the success of a product.

  1. The first time, my software was always unmaintainable and inscrutable and every change in the code led to surprising results. I thought I could do without explicit architecture. An expensive lesson!
  2. The second time I had a strict teacher: the software architect of IBM in Rochester, MN. Their message was clear: "Christian solve your problems in the model". And if I did not comply, they would end the cooperation. Strong message, right?

But the IBM guys were right. The actual development and value creation happens during the development of the software - and (hopefully) not during programming. Anyone who does not want to understand, pays in several ways:

  1. It takes longer because iterations and rework succeed faster in a document or on a flip chart than inside the code. 
  2. One develops potentially unsafe products because the risks cannot be controlled by insufficient strict modularization.
  3. A clean, easy to understand and consistent architecture is a mandatory requirement for a maintainable software. "Historically grown" I count towards the taboo words of this context.

Pay attention on the regulatory requirements for software architecture

So, get it right, solve your "problem" (requirements) in the (software) architecture and not during the coding. This is also exactly what the IEC 62304 requires.  

Are you unsure how to do this? Do you need someone to assist you in creating a precise and law-confirm software architecture?  Contact us now, we would like to help you!

Mistake #2: No standardized notation as UML

The requirement of IEC 62304 to document the software architecture, resulting in some developers knee-jerk opening PowerPoint and painting any box.

That being said, these boxes usually do not reflect the correct architecture, such diagrams are partly value-free. Because a model is only meaningful if the notation elements are defined. But what does an arrow mean by ones "own" modeling language?

  • A dependency relationship?
  • An association? Composition or aggregation?
  • An inheritance relationship?
  • A data flow direction?
  • A sense of method calls?
  • An implementation?

Before you invent your own notation, please use UML. More than a dozen types of charts are available that allow you to pretty much be able to express everything you need to develop software conceptually.

That way, you meet the requirements according to IEC 62304 automatically.

Review/Verification of the Software Architecture

The IEC 62304 requires that manufacturers test the software architecture, the standard speaks of verification. The most important aspects of the examination should be:

  • Are all software requirements met? Check with traceability matrix or tools
  • Is the risk management file updated? Are all risk-minimizing measures in the architecture implemented? Are risks that arise from the choice of software architecture, analyzed and controlled?
  • Does the software architecture document the requirements of the development plan?
  • Is the software architecture so evident that the developers can implement them without further inquiry?

Review of software architecture as RPG

The architecture is only good if it contains components (at a tier architecture the layers should be maintained in an isolated way (i.e. truly component-oriented)) and if it is appropriate to comply with the system specification.

At least you can check the latter during the architectural review effectively with a role-playing game:

One person plays the part, for example, of the GUI (i.e. dialog and/or presentation layer), another person plays the part of business logic. Then, the GUI screens its screen masks and sees what it has in terms of objects that are of use. If there is, for example, a table that displays all female patients older than 65 with a nephropathy and with a haemoglobin level below 10 mg/dl and with a specific EPO dose, then the "GUI-actor" asks its business logic colleague to obtain this information exactly and to explain what methods cascade accurately, calculates and returns this data in the UML diagram.

You go through this game not only for all the objects of use, but also for all tools. The GUI representative asks the business logic representative, for example, to describe how the architecture responds to a click on the ‘save’ button. With an ultra-thin client, there should be a method in the backend for each object and every tool.

The aim of the person who takes the role of the GUI is to prove that the architecture is unable to obtain or store all the necessary data. After a while - my suggestion would be that - the two "actors" should switch roles. Believe me, there is no other way one can check an architecture. This requires, of course, that you have modeled your architecture.

Bad Software Architecture: A Problem in the Audit?

Representatives of most of the notified bodies have visited me at the Institute, to talk about compliant software development. This gave me the opportunity to ask how they would deal with bad software architectures.

The answers were clear to me, but also surprising: The auditors would make a note of a non “finding” in a poor software architecture. A badly documented software architecture (regardless of whether the architecture itself is good or bad) could, however, cause a problem in the audit.

I can, on the one hand, understand this way of thinking, because there is no law and no standards (e.g. IEC 62304), which dictate a good software architecture. On the other hand, a bad software architecture becomes a problem if it is, for example, responsible for ensuring that risks are not controlled or even caused because of it.

Quality of documentation 

Good documentation of software architecture is a condition in order to assess the quality of the architecture.

For the auditgarant I have created several video training sessions, where I explain step by step how to not only write a good documentation, but also how to create a good architecture. 

As a guideline, for a "good" documentation of software architectures, you can download the ISO/IEC 42010 (good Wikipedia article) or the template of arc42.

Quality of architecture 

This raises the question of the criteria and the assessment criteria for the quality of the architecture. The architecture is mainly driven by "non-functional" requirements. That means that you should check whether a sufficient number - which is relevant for the architecture - of quality requirements are defined. This is where most software/system requirements fall short. And you have to specify a method with which you check the "appropriateness" of the architecture for the quality requirements. For example, ATAM or SAAM. This is where we stumble upon the next problem: Very few people know it, let alone master it. 

With the video training of the auditgarant, you will learn, step by step, how to document a "good" and standard-compliant architecture. 

Need more help in creating or evaluating ("reviewing") your architecture? Get in contact with me now, I'd like to help you!

Learning Materials

When it comes to documentation of software architecture for medical products, I normally face two types of people:

  • The software developer, who are often faced by the problems in the sense of lacking knowledge in understanding what one has to document to be able to meet the legal regulations (as well as FDA) and the standards.
  • The regulatory affairs manager, who actually knows about legal procedures and standards, but not exactly understands how to meet the requirements in the practice without having massive overhead. 

Because of these reasons, the training videos in auditgarant will help you understand more how to develop and document your software architecture compliant to the required standards. 

In these trainings, you will learn about:

  • why you have to create and develop an architecture
  • what are the criteria of a good architecture
  • what are the regulatory requirements that you need to fulfill
  • how to be able to document an architecture
  • how to evaluate/review/verify an architecture

With this knowledge, you will succeed in the next audit!

Personal Support

In case you have documented your software architecture, we would like to help you with a professional review. We can even give you a quick, valuable feedback at minimal cost.