The End Of DevOps
DevOps, for those of you not focused on software quality, is a way to get the operations people and coders together to get stuff done faster. DevOps was the rage but it failed to move the needle much more than 25%.
25% faster is pretty good but not transformative. Nobody transforms with fractions. Transformation means you move a decimal point. Not happening with DevOps.
If we could create a perfect QA environment, forget costs, what would it be?
First, it must test 100% of the code, against every real-world scenario, continuously, 24/7.
Using traditional technology, this is impossible. It would cost more than the system being tested. QA, after all, must be practical and pragmatic.
This becomes quite possible when applying a disruptive technology like System Oriented Programming.
System Oriented Programming is the next step beyond microservices, delivering a micro APP that contains all it needs to perform in its own little tech stack.
Results are remarkable. Apps built in days or weeks, or for a major legacy conversion, a quarter. They cost 1/10th the cost of the legacy app. They run 1,000 to a million times faster on hardware you can hold in your lap.
OK, so what does this mean for testing? What does it mean for system quality?
One can now build a parallel app for that gnarly legacy, transactional system (like customer care, account management, and billing systems) in a fraction of the time it took to build and/or make changes to the original. It runs on inexpensive hardware and costs a fraction of what the build would have cost.
This new system runs parallel with the legacy app being tested. Every line item, report, output, or result is reconciled.
There are now two systems, written by different teams, using not only different code bases but entirely different tech stacks. No Oracle, no VMware, or other legacy software inside.
If the output is the same, based on the same set of input data, the parallel app is certain to be correct.
Because System Oriented Programming apps run so fast, testers can take 10 years of historical transactions through the parallel app. They reconcile in minutes.
Thus, 100% of the use cases that the company faced in the last decade are tested to the line-item level. If they match, there is a certainty that the parallel system runs just like the legacy one. And it tested every scenario that the firm saw for a decade. Thus, the parallel system is considered ‘proven’ to be a twin of the original.
The next step is to use the proven parallel system to validate a change made to the existing system. This is where the true value of this approach is recognized and financially a no-brainer. When the change is made to the primary system, the parallel app is modified via System Oriented Programming to handle the same change.
If both systems, when large data volumes produce the same results, chances of both systems having produced the same false positives are infinitesimally small and nonmaterial.
If systems differ, the differences are investigated. However, this process is so short compared to the laborious process of comprehensive end-to-end testing, regression, and edge cases, value becomes immediate.
A side benefit, unique to transactional systems, is errors or subtle fraud built into the system or slipping through are immediately identified.
Why is this better than DevOps?
Well, first, it costs a fraction of a DevOps team. It covers every scenario the customer has encountered for the last decade or more. It runs 24/7 so every new feature is tested continuously, with 100% test coverage.
Unlike DevOps, the customer doing parallel system testing has transformed their process from testing to proving. Using the legacy system as the reference system, transactions prove that under every circumstance the company encountered in the last decade or more, the two systems agree.
Or they don’t. And if they don’t, the developers have immediate feedback into what is different against every historical scenario.
One has transformed from testing to validation. Using certain historical outputs, one can trace backward to find any problems. Months of setting up testing scenarios are over. The costs for hundreds of testers disappears. Tests are continuous, 24/7, cover 100% of the code.
Parallel system testing has an even greater benefit. Over time, when the customer gains confidence that the parallel System Oriented Programming system is correct, the legacy system can be retired, and the customer gains the financial benefits.
Go forth and prove.
Reprinted from Software Executive Magazine On Line