The Nexus of ALM, Compliance, Liability, and Governance
More dreadful news headlines for automotive interests. This news further demonstrates the growing pervasiveness and importance of software within the automotive domain, and a cautionary tale with respect to software development processes, organizational management, governance, liability, etc. Without naming names and re-hashing the specific details of the incident, this essentially winds up being a case of an implemented software-enabled feature that thwarts mandated compliance.
How could something like this happen? And now that it has happened, what’s next? Several scenarios certainly seem plausible, though some more than others.
Hypothesis #1: an honest mistake
It was just a defect implemented by mistake… the result of some uncontrolled change, or maybe some manner of experimental and/or diagnostic coding that was inadvertently not removed from a production build. Certainly this would imply that whatever Application Lifecycle Management (ALM) process exists is exceedingly immature and/or is of extremely low capability, or there just isn’t an ALM process of any kind in place at all. The mere act of simply installing Polarion ALM would likely have prevented a scenario such as this one (unless of course Polarion was installed, but never used).
How ALM might have mitigated
Polarion ALM provides the needed alignment to get requirements management, version control, change and configuration management, test and quality management, issue and defect management, with full traceability between each area — all working together in a true lifecycle, across all projects, teams, and collaborators, no matter how disparate, such that any/all software releases are of high quality. There are no such things as uncontrolled changes, forgotten code, insufficient scrutiny, or a myriad of other development process issues when using Polarion solutions.
Hypothesis #2: the other guys “done it”
A business partner is responsible. This was something introduced by the code within a procured component. Once again this would imply that whatever supply-chain management or processes for interaction with suppliers that may exist, likely are immature and/or of low capability. Effective supplier interaction, especially in the current engineering paradigms of tightly integrated software, hinges on accurate and precise specification of requirements, and the communication between OEM and suppliers.
Depending upon the component and business relationship, suppliers may assume obligations of testing and quality assurance, and the linkage of such QA processes to requirements is pivotal, as well as the communication of testing outcomes to the OEM. Once procured, OEMs must ensure that integrative testing is sufficiently traceable to all requirements, that issues or defects are appropriately managed to resolution, and adherence with regulations and relevant standards is assured and provable for compliance purposes.
How ALM might help
ALM is very much a factor where software is concerned, and ideally must become part of an integrated Product Lifecycle Management (PLM) approach. Here again, Polarion ALM provides the needed alignment and collaboration for requirements-driven activity among all supply-chain stakeholders, configurable workflows and various mechanisms for the conveyance of requirements and artifacts between OEM and supplier, plus the needed linkage and traceability for QA and compliance purposes. Polarion’s ALM-PLM integration capabilities also enable ALM to rightfully become a key facet of a comprehensive product delivery process.
Hypothesis #3: Out and out skullduggery
It was the doing of rogue management. Because the compensation of some person or persons of requisite authority was linked to a sales or revenue goal, these individuals may have made a calculated decision that compliance was going to adversely affect potential sales (and threaten their anticipated bonus pay). So they decided a clever solution would be to implement a software enabled capability that would allow their vehicle models to only appear in compliance, such that sales could meet targets and assure that everybody can collect their expected bonuses, e.g., this was by design; this was a requirement. Obviously such a scenario involves corporate governance, the tone-at-the-top set by executive management, and the internal controls established within an enterprise that would serve to prevent or detect such actions on the part of business unit or product managers.
ALM might discourage it
Since the mechanism of circumvention utilized is software-enabled, plus software being increasingly the central fixture that enables many product features, the software development process is very much a part of an enterprise’s system of internal control and corporate governance. In using Polarion ALM for example, software development workflows can support and enforce internal control objectives. Collaboration capabilities define roles, permissions, and approval relationship chains that can enforce a process of review, annotation, resolution of comments, and approval of work items.
Work items are linked to one another and are fully traceable between one another, e.g., approvals are comprehensive, contextual, and are enforced to remain current in the face of dynamic activity and iterative change. Interfaces and reporting provide the views appropriate to responsibilities, including global views of the workflows, project status, and approval landscape necessary for oversight and internal auditing.
The Fallout: “This is gonna cost ya, pilgrim!”
No matter the hypothetical scenario, a catastrophe occurs when the outcomes are revealed. In the case of matters which are the subject of recent news headlines, the revelation of outcomes stems from the actions of an industry watchdog group, who then alerted the relevant regulators, which caused them to conduct their own investigations –providing yet another cautionary lesson that nothing in this 21st century is simple or isolated.
Regulatory compliance and product defect liability are woven into the fabric of 21st century markets. It certainly was apparent before, and now such an incident makes it obvious. To forget this lesson about total quality management (TQM) is to assure the absolute failure of products, and even entire brands.
What’s next?
In any situation involving regulatory compliance violation, product liability, and overall governance, the stakes are high. Significant monetary penalties or damages are likely involved. However, those might only be the tip of the economic consequences since entire brands can become tarnished, and the commercial viability of even products not involved can become threatened.
There may be civil or even criminal liability considerations. In other words, even if a deliberate deceitful practice on the part of an organization’s managers, now there must be a process to determine culpability, which will serve as the basis to assess liability and penalties. The Executive Management team in such a situation is confronted with a monumental investigatory obligation to get to the bottom of the problems.
Likely the investigations will be under the scrutiny by, if not at the direction of regulatory authorities, who will demand assurances as to the comprehensiveness of management’s determinations of root causes, timing of events, culpability of responsible parties, etc. Since the issues at hand were introduced via software, the bulk of investigative procedures are going to concern the process of software development.
ALM in the spotlight
Thus, ALM is not only the subject of investigation, but also the tool used for investigative purposes… provided it is sufficiently capable. Polarion ALM’s forensic-level traceability, comprehensive version control of everything involved in a development effort, and its ‘Time Machine’ feature providing visibility to the historical states of any project, would be of enormous benefit.
Polarion ALM’s inherent functionality, combined with it documentation and reporting capabilities, would provide compelling assurance with respect to process, as well as to forensic determinations of events and outcomes.
Software provides the core of so many products, particularly the features and functions in complex products. Not only is the scrutiny of releases and delivered products necessary, but also the scrutiny and oversight of the lifecycles whereby releases and products are the result –both are fundamental management imperatives.
