The Philosophy of Application Delivery:Was Plato a Model-Based Tester?

This is part one of three of the “Philosophy of Application Delivery” eBook. The eBook contains Curiosity Software Ireland’s musings on the nature of effective application delivery, while introducing VIP, the new “Rapid application assembly Framework”. All of this is done within a brief tour of several major schools of Western philosophy from the past two millennia.

The Philosophy of Application Delivery Part 1: Was Plato a Model-Based Tester?

We learn in high school philosophy that ‘everything is a footnote to Plato’. Everything would have to apply to application delivery too. This blog considers insights for quality application delivery from Plato (427-347 BCE) and his pupil Aristotle (384-322 BCE).

Observation, observation, observation

Aristotle is often hailed as a founding figure within empiricism. If we want to know about something, observe it; to know what virtue is, Aristotle describes in the Nicomachean Ethics, observe the virtuous person.

If we look to Aristotle the man, we find someone who continually experimented, and meticulously compiled their findings. Aristotle’s volumes of zoology and natural scientific observations, for instance, have proven so rich that some of their more surprising conclusions are still being verified today.

So too with application delivery. Inherently empirical, we record user needs, produce code, formulate tests, run them, and record the results. These assets are created based on a prior understanding of a system, and what is observable within it. We then correct our understanding when previously unknown elements are uncovered, feeding this back into requirements and TestDev assets.

The more we observe, the more we learn. This is true from the initial and ongoing collaboration between requirements gatherer and user, to smoke testing, end-to-end automated functional testing, and eventual user acceptance tests. These observations can then be fed back into the documented understanding of the system, working like Aristotle to fully understand the user’s desired functionality.

An eternal blueprint?

Throughout this process, we need to know how the system is intended to function. Testers, for instance, need expected results with which to compare and verify actual results, considering how the system works in relation to the recorded understanding of how the user wants it to work.

This takes us to Aristotle’s predecessor and teacher, Plato, in a sense the first model-based tester. In Plato’s theory of forms, we are told that every instance of what exists in our world is a reflection of an ideal ‘form’. In the world of forms, there is the form of the ideal chair and the ideal good, both of which are found reflected in the world of matter.

Only the philosophers who liberate themselves from a focus on the material world can climb to the world of forms. The rest of us are sitting in a cave, watching comforting shadows pass by on a wall in front of us, mistaking them for true forms.

Figure 1: Plato’s Analogy of the Cave.

These philosopher kings plan and manage Plato’s Republic. They are responsible for contemplating the blueprint of the ideal city and implementing it in practice. This blueprint is not absolute or timeless, with each philosopher king sitting for a set period and improving the plan for the city.

In the traditional delivery cycle, elements of this approach can work hand in hand with the empiricism discussed above.

Stakeholders across a sprint or delivery pipeline act as philosopher kings, working to ascertain the user’s desired functionality, while validating that it is being fulfilled. They translate this understanding into a blueprint of the ideal system, housed in requirements and models. From this blueprint, code and tests are derived.

The tests are then executed, with the results compared to the ideal system. The blueprint itself can then be updated to reflect any new knowledge of how to fulfill the user’s needs, before updating and retesting the system in the next iteration.

Poor stakeholder alignment: when the delivered system is only a shadow of its true form

In this traditional delivery cycle, however, challenges emerge by virtue of poor alignment between stakeholders. Business analysts will still often formulate requirements, pass them to developers, who then convert them to code. Testers might then translate the requirements into test cases, laboriously attempt to locate the right data to execute them, and then try to communicate their results accurately back to the developers.

Each stage introduces the potential for miscommunication and an ever-greater degree of inherent uncertainty. Delays further mount as a result of the manual labor of converting requirements, development, and test assets from one stage and format into another.

This is true in Agile environments, where sprints frequently resemble mini-waterfalls, and silos engrained in organizational processes disrupt the information flow. Meanwhile, differing technologies quickly pile up in the individual teams, exacerbating the labor of having to assemble functioning systems and automated business processes.

Introducing Visual Integration Processing

Once-called “business” stakeholders and those with “deep” technical skills need to be brought into closer alignment. Meanwhile, the siloed, conveyor-belt approach should be abandoned in favor of parallel productivity.

“Low code” capabilities offer one way to achieve this, when implemented with the right tools and processes. “Technical” teams can enable the “business” to leverage and re-use their code and automation components in future development cycles, freeing developers and testers to focus on delivering continual innovation.

“Visual Integration Processor” (VIP), the new solution from Curiosity Software Ireland, can support organizations in achieving this stakeholder alignment. Users can collaboratively build a central repository of re-usable components, which includes automated business processes, as well as system logic like code and message calls, and automated test scripts.

Business Process Automation and the “Business-DevTest”

This central repository functions like a library of re-usable lego blocks, allowing stakeholders with minimal coding knowledge to leverage the efforts of DevTests and automation engineers. A BA, for instance, can drag and drop the re-usable components to the VIP canvas, quickly assembling them into a functional model or automated business process.

A BA might use this model-based approach as a form of declarative programming, assembling functioning prototypes of a feature or component, equipped with the data and service calls needed to execute it. Testing can therefore occur in parallel with ideation, allowing the “Business-DevTest” to exercise fail-fast experiments against their model.

BAs can thereby garner early insights and eliminate defects before the time and cost has been spent developing and testing the feature of automated process flow. The model-based approach used in VIP is furthermore flexible, so that the first-day testing is run as the model is being created and updated according. BAs can thereby work like Plato’s philosopher kings to better their understanding of user needs, and as Aristotle to improve the corpus of observations.

VIP can similarly remove all-too-familiar bottlenecks with easier, accelerated Business Process Automation. BAs can quickly work from the repository to assemble working flows to automate laborious tasks, without having to constantly reinvent the wheel.

A simple but all-too-common example is the proliferation of PDFs in many large organisations, and the laborious task of scraping data from them to put into another, usable format like spreadsheets. VIP has been used to automate this process, freeing BAs to focus on identifying user needs, and driving further innovation and efficiency savings.

Figure 2: A VIP flow used to convert a PDF attached to a supplier email into Excel, before validating the data it contains and exporting it to the BI Dashboard. Looping capabilities mean that this is a continual process, whereby the upfront, one-off investment in creating the flow quickly pays for itself in time saved.

“Low Code” not no code: Developer Process Automation Frees up Test and Development Cycles for Innovation

The role of the techie remains, but their time is freed up for innovation, while the value of the resources created via hand-coding or scripted automation is maximized by virtue of the re-usability of these one-off labors.

Many tools aim for enhanced or simplified communication channels between business and technical stakeholders. This is invaluable, and VIP offers integration into Slack and Facebook as part of its “ChatOps” functionality. However, VIP further empowers individual stakeholders to maximize their self-sufficiency and efficiency, leveraging the one-off labors of others to reduce the delays associated with repeated or overlapping efforts, and repeatedly asked questions.

The rate of innovation is thereby increased. Developers, testers, and DevTests can further benefit from VIP’s “Rapid Application Assembly Framework”. This not only allows them to re-use individual components created by others, but reduces the efforts of manually integrating the moving parts of a system.

VIP instead allows systems or process flows to be assembled rapidly and visually, better understanding the complex logic and working to avoid the frustration when a hand coded integration falls down due to a mystery component failing.

The labor of hand coding the “plumbing” or glue that holds a system together is also thereby reduced. VIP facilitates this through connectors into spreadsheets, popular data formats, APIs, test automation frameworks, and project management tools, to enable smooth process automation enterprise-wide

Citizen Developers as Philosopher Kings

VIP accordingly uses a model-based approach to accurately capture an evolving system or automated business processes. This facilitates the rapid assembly of test automation frameworks, efficient “low code” and hand code development, and accurate business process automation.

New insights into the system or user needs can be garner continually with this approach, iteratively updating the central repository of re-usable objects and enhancing the models in accordance with the latest observations. Distributed teams can collaborate like an organized collective of observant Aristotles, using automated tooling to facilitate thinking and faster experimentation.

These observations feed into a flexible model of the business process or system under test and development. However, whereas the maintenance of the ideal Republic was the prerogative of philosopher kings for Plato, VIP aims to facilitate a collaborate approach between “citizen developers” working enterprise-wide with maximal self-sufficiency for maximal efficiency.