The use of post-incident artifacts in high-performing organizations.

The explosive growth of the Internet of Things (IoT) devices raises serious concerns for a user's privacy and security because the existing software framework on these devices often support various default features and generate large data sets. Moreover, many IoT devices incorporate a manufacturer-owned cloud-based back-end support to process and store the generated data while simultaneously sharing with third parties. Clearly, in such an industry-driven environment with the desire to use the IoT data as a revenue stream, it is a challenge for users to control IoT data. Device manufacturers utilize an opaque software design where user data is generated and stored with little transparency. Manufacturers use EULAs as a legal construct to protect a manufacturer's legal standing and to explain a device's behavior, however this explanation is vague and lacks the necessary details for a user to determine a device's acceptable use and it has become increasingly difficult for users to secure and maintain their data. Fortunately, as the privacy minded user base of IoT devices grows, the manufacturers will be forced to implement a new framework that can enable users to have more control on the creation of their IoT data, and to store/disseminate such data in a secure and private manner. In this paper, we address this lack of transparency from manufacturers and address the issues of privacy and security by proposing a new framework called Bulwark, for manufacturer use on IoT devices and mobile applications. Proposed framework enables the user to generate and manage a set of data controlling rules, and store the result in their personal cloud account, while providing a dashboard data reporting tool enabling data transparency and supporting good user choices. The user's ability to access, disseminate and secure IoT generated data, is now available within our proposed framework. Using reverse engineering, simulation and implementation of open source solutions, we demonstrate support for a set of common devices. Each device executed the framework, while communicating with a mobile application and cloud services. Rules were generated for each message and telemetry was returned to the mobile application for dashboard rendering. We stored generated data in the cloud using our own account, while maintaining the free tier for each of the cloud services. Network usage increased between 4% and 9% while storage size grew between 0% and 2% larger, as compared to using the device without the framework. Our framework demonstrates support for a multitude of devices, by either open source or support for similar feature sets. This framework is easy to integrate and we anticipate wide spread adoption.

O f all the traits the technology industry is known for, self-reflectivity and historical introspection don't rank high on the list. As industry legend Alan Kay once famously quipped, "The lack of interest, the disdain for history is what makes computing not-quite-a-field." It is therefore somewhat cognitively dissonant, if not fully ironic, that the past few years have seen renewed interest in the mechanics of retrospectives and how they fit into the daily practice of our craft. Of course, retrospectives are not new, in software development at least. For more than 15 years capital-A Agile software development methods have been extolling the virtues of a scheduled, baked-in reflection period at the end of each development sprint. (Whether these actually occur in organizations practicing Agile remains an open question.) Those same 15 years have also seen a tectonic