Productivity, Feedback and Continual Learning
While reading Peter F. Drucker’s Management: Tasks, Responsibilities, Practices[1], I came across a statement I thought very relevant to the modern business despite being written nearly 50 years ago (1973). Drucker wrote:
“To enable the worker to achieve, he must first be able to take responsibility for his job. This requires: 1) productive work; 2) feedback information; and 3) continuous learning”.
These words were written at a time when more people than today were employed in manual industries such as agriculture, mining, manufacturing, and construction[2]. In 1971, the manual labour sectors made up a little over 41% of the workforce, but by 2016, this had shrunk to 16.4% of the workforce[3]. Today, about 85% of workers are considered knowledge workers, delivering services rather than physical products. For example, many work in finance, banking and insurance, retail and wholesale distribution, or professional services. Even though Drucker’s statement was said during different times, it struck me as being very relevant even in today’s service-oriented industry.
Productivity
Productivity is the rate at which goods or services can be generated. However, there is a deeper meaning to this. Productivity at the expense of value to the user and at the expense of quality to the user is of no benefit to those who use the services or products. Therefore, productive work should not be measured solely in terms of speed to market or quantity of output but should also be measured in terms of the quality of the output. Speed is a parameter, but not the only parameter. Software engineers can write more lines of code more quickly; they can run builds faster and can promote code to a production environment at a click of a button. However, if users are then presented with a defective solution that fails to meet their needs, or exposes them to poor quality, what use is speed to them? Quality must be built in throughout the process: from design and development, to testing and deployment. Security is a subset of quality. Without security, users are at greater risk of having their personal information compromised; they expect their personal data to remain confidential, un-touched, and available when they need it. They expect this when they use the services organisations make available to them. If their data is compromised due to a focus on speed rather than quality or security, what use is speed to them? So productive work consists of producing high quality products and services that provide value and comfort to the user of the products and services.
Feedback
This leads us onto the second requirement: feedback. The nature of the information being fed back must be timely and relevant. This means that there must be multiple feedback loops flowing from right to left all the way through the entire system. Inevitably we must always respect the feedback from the customer or end-user of the product or service, who ultimately has the final say on the quality and value of the product or service; a customer has the right to choose another supplier if they are dissatisfied with the product or service. Feedback is internal to the organisation as well; the consumers of output from a process must also have the facility to provide timely feedback to the individuals or teams that produced the output. Internal feedback must be based on quality and value; does the output meet expectations in terms of the quality of the product or service and the value to the rest of the system? Of course, speed is important in the modern digital world, and feedback can include data about speed. But as stated earlier, it is not the only parameter that is important to a system.
At this point, it is important to understand what is meant by a system. According to W. Edwards Deming, the system is defined as “a network of interdependent components that work together to try to accomplish the aim of the system”[4]. This is echoed by Drucker who states, “Business enterprise is a system of the highest order: a system the parts of which are human beings contributing voluntarily of their knowledge, skill, and dedication to a joint venture.”[5] Russel L. Ackoff offers multiple definitions of various systems, but describes a generic system as, “an entity which is composed of at least two elements and a relation that holds between each of its elements and at least one other element in the set. Each of a system’s elements is connected to every other element, directly of indirectly.”[6] A system, therefore, is a collection of interdependent components working together for a common purpose of the system. The boundaries of a system are not explicitly defined, but normally encompass a collection of interrelated groups, such as an organisation (group of departments), a market sector (a group of organisations), or even a whole country. The larger the system, the greater the benefits to a larger population; albeit with greater difficulty in managing. Having an appreciation of the system is key to continuing productivity. If you are only focused on a part of the system, the system will not benefit. For example, if a department is only responsible for its own costs within an organisation, it will look to make savings without consideration of the impact on other departments within the organisation, thus increasing the overall cost to the organisation. Thus, the security team that is reluctant to allocate funds for the tools that provide greatest benefit to the system, ultimately leads to increased costs of security within the system. The outcome is weaker security, lower productivity, and lower profits for the business. Although, the security team “wins” by meeting its objective of keeping its costs low, the business loses, and ultimately, the security team loses too.
Figure 1 — A system, its interdependencies, and its communication channels
Due to the interconnected nature of a system, communication channels must be available across the system. This allows its components to share with and consume from other components with which they interact. This means that components should have autonomy in selecting the data they collect, while they should also make available all relevant data from which other components can select what they need. Broadcast relationships should be the default communication methodology, while direct one-to-one and one-to-many relationships should be avoided or kept to a minimum.
From a security perspective, there are many potential feedback loops within systems involved in software development. Development engineers need to see the security status of their code while they are working within the Integrated Development Environment (IDE). They also want to know as soon as possible whether their third-party libraries contain known vulnerabilities that may expose their products and services to threats. Operations engineers need to know the security status of the infrastructure, whether bare-metal or cloud-based, as well as knowing whether supported VMs, container orchestration technologies, and automated pipelines are configured securely. Security engineers need real-time feedback on potential security incidents. Product owners need feedback on potential security flaws in their products. Customer feedback is also important; they should have the ability to report any potential security issues with the products and services they use. They must be able to report suspect behaviour and inappropriate use of their data, or safely inform the organisation of usability and accessibility problems, such as difficult registration or authentication workflows. Ultimately, the feedback loops should reflect the interdependencies between the various functions within the system (in other words, individuals, teams, and customers).
Continual Learning
The final responsibility of a worker is to continually learn. Learning is the act of gaining knowledge, not just for personal growth, but also for the growth of the business. The business benefits from knowledge through the improvement of its products and services. Everyone has their own preferred method of learning. Successful organisations provide different options for their staff, such as training courses (online and co-located), subscriptions to training platforms, and support for higher education. However, for greater success, organisations and their staff should focus on self-development through a process of continuous learning and improvement as part of the daily activities. When learning is carried out in the context of the work being done, the knowledge gained is relevant to the activities important to the business and the individual.
It is important to understand the distinction between learning ‘information’ and gaining ‘knowledge’. For example, learning about threats such as malware, worms, or viruses, including Stuxnet, WannaCry, and Petya, is not the same as knowing how they work and knowing how to protect your systems against them. Likewise, learning the list of OWASP Top 10, although informative, does not mean you know how security weaknesses are exploited, and know how you can defend against them.
To gain a more meaningful understanding of security, individuals need to learn the impact of producing vulnerable software by experimenting with methods used by attackers to exploit weaknesses. Experimentation builds knowledge and improves the security and value of the products and services being developed. The process of learning starts with a theory, an assumption to validate. The next step requires the construction of a plan to test the theory. What are the input values and the expected state following the processing of those values? Based on the theory, the next step is to conduct the experiment in accordance with the plan created in the previous step. The outcome of the experiment should be documented, the results noting actual values, not assumed values.
The next step is crucial to the success of the experiment as a tool for learning and improvement. This is the process of studying the results. What do they tell us? Have they validated our assumptions? Are there values we did not expect? Are our assumptions wrong? Even with expected results, we have learned something new — we have learned that our assumptions were correct. Before then, they were only theories.
After studying the results of the experiment, we can make an informed decision on how to proceed. It is important to not do nothing; we must do something. We can decide to refine the solution further, discard the original theory and devise another, or create a new theory to test. This feeds into a new iteration of the cycle.
These steps were defined by Walter Shewhart and Deming which they encapsulated in a cycle of continuous learning and improvement, often referred to as the PDSA cycle.
Figure 2 PDSA cycle (adapted from W. Edwards Deming’s New Economics)
We can adapt this to the way we build security into our software delivery processes. Starting with a theory such as “using a SAST tool, we will reduce the number of security weaknesses in our software”. From this statement, we see that we need to be able to collect evidence to assert whether our theory is correct or not. This may be the most difficult element, but evidence could be collected from various sources, such as Security Information and Event Management (SIEM) tools, penetration test results, and code reviews. It is crucial that evidence covers a significant period and not a moment in time, to capture random variations over time and trending data. The next step is to run a SAST tool over a significant time span while continuing to collect evidence as before. We will have new data from the actual SAST tool to add to this evidence. Having collected the data, we need to study it in the context of the theory on which we have based this experiment. What have we learned about the effect of the SAST tool on the number of security weaknesses within our data? Has there been an improvement in the system? Some of the questions we ask will be answered definitively by the experiment. But other questions will remain unanswered, and indeed, new theories will evolve to feed another PDSA cycle.
This is a simplistic overview of PDSA in action. However, there are several PDSA cycles in play during the adoption of SAST tackling multiple theories that allow us to learn continually about static analysis methodologies within the context of the software we develop. As a result, we either improve the outcomes of running SAST tools, or develop new models for analysing software for vulnerabilities.
The PDSA cycle should be applied as part of the education and improvement process. In addition to this, individuals should continue to educate themselves using the tools they prefer (reading, watching videos, hands-on learning, tutorials, study groups etc.). Since we have moved from a manufacturing economy to a service economy, our greatest asset is our knowledge and experience. Therefore, we must improve what we know daily and develop the skills to improve what we deliver, with the same commitment as craft-workers who hone their skills and sharpen their tools daily.
Conclusion
To conclude, productivity, feedback and continual learning are essential components of the way we develop products and services. The philosophies of Drucker, Ackoff and Deming continue to influence modern-day thinkers. In their book on DevOps, Gene Kim, John Willis, Jez Humble and Patrick Dubois encapsulate this in their three ways of DevOps model[7]. Productivity is dependent on the performance of the entire system (first way); feedback is shortened and amplified (second way); and a culture of continual learning and improvement is fostered (third way). Within the service economy of modern industry, manufacturing output has been surpassed by knowledge output. Where success in manufacturing required producing quality components within a product, success in the service industry requires improvements in the quality of what we know, not what we make. DevSecOps therefore, by association, requires improvement in security knowledge throughout the entire system.
[1] Drucker, Peter F., Management: Tasks, Responsibilities, Practices (HarperBusiness 1993)
[2] There are three generic categories of industries: 1) primary (primarily agriculture and mining); 2) secondary (primarily manufacturing and construction); and 3) tertiary (services)
[3]https://www.ons.gov.uk/economy/nationalaccounts/uksectoraccounts/compendium/economicreview/april2019/longtermtrendsinukemployment1861to2018#the-evolution-of-sectoral-distribution-of-employment
[4] Deming, W. Edwards, The New Economics for Industry, Government and Education (3rd edition, MIT Press, 2018) p35
[5] Drucker, Peter F., Management: Tasks, Responsibilities, Practices (HarperBusiness edition, 1993) p508
[6] Ackoff, Russell L., Ackoff’s Best — His Classic Writings On Management (John Wiley & Sons, 1999) p48
[7] Kim, Gene; Willis, John; Humble, Jez; Dubois, Patrick The DevOps Handbook (IT Revolution, 2016)
