When thinking about trustworthiness it is not enough to think of the trustworthiness of a component, be it hardware or software or a technology like AI, since trust in the outcome and the consequences depend on the entire system. This system consists of the organization and people who have accountability and maintain governance, the architecture, design, and technologies which must have sufficient quality, and the processes used that relate to the integrity and sustainability of the system.
A system also includes the external environment and all that it entails, including expectations, influence, rules, regulations and so on. As an example, privacy expectations can influence whether a system is viewed as trustworthy.
We rely on many systems to function and to do so safely and securely often without too much thought, whether it is utilities such as the electric grid, transportation such as airlines, automotive or rail travel, medical care or the delivery of goods. We normally expect and trust systems to “simply work”. Occasionally we are unpleasantly surprised such as with the fires in California and elsewhere leading to loss of electrical service after the event, planes crashing due to design issues, autonomous cars not negotiating lanes safety, or supply chains being disrupted.
We place enormous trust in the systems we rely upon. As these systems depend more and more on software to function it becomes essential to understand software and in particular how to have software that can be relied upon for a trustworthy system.
Trusting software requires confidence in the organization that produced it (“Do they do things in a way that inspires confidence? Does the leadership care about quality, safety, and so on or just profits? ” etc.), confidence in the actual products (“Was the airplane assembled properly or were incorrect bolts used?”), and confidence in the service associated with the system (“Is maintenance performed regularly and properly?”).
We have just published a new article on Software Trustworthiness Best Practices. In this paper we outline the entire lifecycle, including the importance of communicating and validating requirements, proper architecture and design, providing enough support for implementation and testing (including tools), validating, operating and decommissioning software. We also raise the value of software protection which is not always considered. The following diagram from the paper shows the lifecycle:
The paper includes practical discussions of issues such as software updates, end-of-life strategy and software protection – all topics that can be ignored when focused on software implementation. The appendix includes a software lifecycle checklist that should be helpful as well as some examples of failures related to software.
Software trustworthiness is essential to creating trustworthy systems and considerations of the topics and practices in the paper should help with the journey toward more trustworthy systems.
There is a certain time frame (typically 9 months) to have a baby. You cannot accelerate the process. If honey hardens you can soften it in warm water but it takes time, boiling water won’t make it faster – it will just ruin the honey. You do not accelerate the process so that you have teenagers the week after they are born, it takes time to get there.
Why in business do we limit ourselves to very short time horizons, when some things take time?
The answer is presumably that we do not know the outcome, so want to manage the risk and limit the cost. With a pregnancy you pretty much can expect it will take 9 months, there is past experience.
That said, there are companies that are doing extremely well since they do take a long view, ignoring the chatter around them. We know who they are.