Power of the -ilities

I have just spent three days refreshing some very competent Systems Engineers about the importance of the -ilities: reliability, maintainability, testability, sustainability etc. I’m sure you’re familiar with them. We all know the processes we wrap around SE to manage -ilities…though in my experience, it sometimes feels like lip service, perfunctory even. And they are regularly left until the bulk of design is nearly complete in the belief that we can’t do anything about them until we have a stable design to work with. As a result, we seem doomed to be perennially dealing with the extra cost of incorporating testability, maintainability, even reliability towards the end of the development cycle. The extra cost should not then be a surprise to us: we know that the cost of addressing issues escalates near exponentially through the development life of a system.

What can we reasonably do about this? One solution to this – talk to the right stakeholders from the start of requirements’ capture. This may seem blindingly obvious, yet all too often we find reliability and maintainability requirements are only flagged late in development.

A good starting point is maintenance. Those who maintain a system not only have to fix the system when it goes wrong, they also need to know how it all works, how to use it, and how to test it too. More than this, they will know what things regularly go wrong and how easy it is to fix them. Very often they have to do all this within the extremes of the operational environment that likely caused the problem in the first instance. From talking to those who have to maintain the current system and leveraging their experience, you can probably determine 80% of your new system requirements.

Other aspects that relate to the -ilities are safety and security. This is because an unsafe or insecure condition will normally result from a failure in some part of the system (reliability), or in the processes that developed the system . The issue here is how we build resilience into the system so that it is robust enough to operate safely and securely despite failures of this kind.

As with other -ilities, late consideration of safety and security means that retrospective measures are needed to address issues that are both less effective and make the overall system design more complex, complexity that itself can reduce reliability. This reinforces the need to incorporate safety and security considerations early in the design. Use the right, independent expertise to identify those conditions that might compromise resilience. Build protective boundaries around those parts, processes and information points that present a vulnerability at the core of the system architecture.

Don’t make the -ilities an after-thought. They have the power to considerably improve the performance of your system as well as the availability. By considering them early and making them core in the design process, you’ll be reducing the cost of your system throughout development, evaluation, production, use and disposal. You’ll probably also make them safer and more secure.

– Dr Kevin Howard