Technology at our KOR

KOR aims to always solve the most important problem, in a way that yields the highest value, in the shortest amount of time. KOR applies the scientific method to software development:

1. Make a hypothesis: “I assume by building X, I will achieve Y which I will be able to verify looking at metric Z.
2. Validate or invalidate the hypothesis as fast as possible.

KOR applies User Centered Design (“UCD”) to gather the requirements in an unbiased way, using user research and high fidelity prototyping. Observing, interviewing, understanding, synthesizing everything heard and observed from the actual user into requirements that can be prioritized.

Note: regulated specifications do not fall under the UCD approach as they are formally defined in advance by the regulator.

Every deployment KOR performs holds a risk of impacting Clients and Regulators in case something goes wrong. Limiting the chance of that happening is essential. KOR firmly believes that the way to decrease the likelihood of deployment failure is to deploy more often. Traditional release strategies group changes together into monthly or quarterly releases. These big bang events hold dramatic amounts of risk due to the greater number of released changes and greater rarity of deployments. If each change can be deployed using feature flags right after it has been developed and tested, the risk of failure is greatly reduced. Feature flags can support either set future timestamps for automated activation or manual activation.

Even minor changes can cause issues. That is why KOR limits the blast radius of production issues by employing rollout strategies. KOR gradually exposes new versions with minimal new functionality to production via a common strategy often referred to as canary releases. After each increment the health and correctness of the new version is measured and compared to the previous version. As long as the automated tests validate the updated version to be healthy and working correctly, exposure to the new version is increased. If, however, the new version is deemed unhealthy, an automatic rollback is performed. This entails the new version is taken out of service and all traffic is rerouted to the previous version. This is done fully automatic to limit the blast radius of production issues.

KOR employees are encouraged to always make backwards compatible changes. Backwards incompatible changes often obstruct running two versions in the same environment at the same time. In those scenarios, strategic rollout is impossible and automated rollback is not an option. Mitigating production issues by patching the newly deployed version and releasing said patch quickly, known as rolling forward. KOR’s release strategy based on small changes flowing quickly to production using feature flags and dark launches allows rolling forward in those situations.

For all regulatory system changes, including any supporting systems, a plan of coordination and communication between regulatory and other personnel of KOR, including by responsible personnel, regarding systems design, changes, testing, and controls designed to detect and prevent systems compliance issues. The KOR CCO of the respective system must approve any changes that may impact the regulatory compliance functionality.