In this blog post our CEO, Daniel Lewis, discusses his experience of software engineering approaches and the direction of the Awen Software Engineering approach.
Agile but Pragmatic
A well known formal definition of the traditional “Waterfall method” (as it has become known today) of project management / software engineering was established by an academic by the name of Winston Royce in 1970 [1]. Royce defined it as a flawed method which is a risky, failure-inviting method. (Note that older and newer definitions are available)
I, personally, have found the waterfall method to be flawed too. When a software project is started, we do not always know all parameters in advance either because the software exists in a complex, ever evolving system, or because implicit/tacit knowledge was not uncovered upfront.
This is why, I believe, some of the earliest descriptions describe the waterfall method as flawed. It just cannot react to the needs of the project/system as it evolves and is discovered internally and externally. I like to see the waterfall method a little like the original game from which Monopoly was derived (known as The Landlord’s Game). This game was specifically developed to show the negative effects of land grabbing on both the economy and on the human psyche - the waterfall method is similar, it was essentially developed to show how the worst of the popular/contemporary ways of working.
With this said, the Agile approach, where projects go through iterations adapting to new information, is not without its faults. The biggest fault that I have seen in agile approaches is that it has become a bit of a soup of buzzwords, where agile project managers tend to run agile projects with as much rigidity as they would with waterfall that the overheads often become too costly to make much benefit.
This is why at Awen we approach software engineering with a pragmatic agile method. A kind of soft agile method. Depending on our clients, we often have to work with a sort of waterfall-like method implemented alongside PRINCE2 or ITIL, but the internal technical work we run our own pragmatic soft agile approach. Do the things which work, don’t do the things which won’t work, minimise overheads and maximise impact. Our approach is always evolving, especially as the business continues to grow, and gaining new people with new experiences.
Security-by-Design
Even though our software engineering project management might seem flexible, there are some things within software engineering which we do not compromise. One such thing we consider as uncompromisable is developing everything that we do with Security-by-Design.
In particular we follow the Cyber Security Design Principles by the NCSC:
Make compromise difficult
Make disruption difficult
Make compromise detection easier
Reduce the impact of compromise
These principles are all based on top of various software development testing techniques and cyber security testing techniques that we employ alongside development.
We are also aware that our software is deployed in highly sensitive areas, where equipment is safety-critical (or at least operations-critical). This is why Safety-by-Design is also a consideration in our software development, and is a key component of our innovative Dot product for asset & vulnerability discovery on Operational Technologies (OT).
Conclusion
When Awen software is deployed and used, you can rest assured knowing that the highest levels of pragmatic software development have been employed, everything has been thoroughly tested and the products and services are well thought through with both Security-by-Design and the industry critical Safety-by-Design. Our software can help industrial organisations reach Industry 4.0 and beyond, pragmatically and securely.
Winston W. Royce (1970). "Managing the Development of Large Software Systems" in: Technical Papers of Western Electronic Show and Convention (WesCon) August 25–28, 1970, Los Angeles, USA.