Supporting ORYX in the Enterprise

The test of a process should not be merely whether it always runs successfully, but how quickly we can recover from failure.

The fact is, if a product was never built from the ground up to be easily supported, there is little chance of achieving a high standard of support within the Enterprise. Arguably, issues with software products can most often be tracked to design and concept.

ORYX, unlike many other software tools, was built from the ground up to be robust and easily supported. By including the following features as part of its core infrastructure, we empower organisations to obtain outstanding recovery from process failure:

Logging

Whether an implementation or a product defect, its crucial that we have as much information about why, where and how the defect occurred. This is why logging is completely integrated into ORYX:

• logs are (unconditionally) created for every activity in ORYX projects
• system and project logs contain important system information
• all log messages are in plain text, wherever possible

Tactical vs Strategic

In the ORYX development life cycle there is an extremely short distance between the tactical (dev) and formal deployed versions of a process or application. This drastically reduces the risk of unexpected failure.

Design vs Execution

Errors tend to occur more frequently in tools where there is a blurred boundary between process design and execution. ORYX enforces strict separation between design and execution activities - there are different versions of ORYX to complement the skills and role of the user.

Inline Quality Assurance

One major failure point within many processes is data quality, or from another point of view, a lack of quality assurance. Many processes complete without any built-in result testing or reconciliation. Many support issues arise even when processes execute correctly from a “technical” point of view.

ORYX processes include all mapping, validation and applicable data tests, including output reconciliation to source. Using these techniques we turn data processes into rock-solid production lines.

Agile Learning Processes

ORYX also introduces the concept of agile learning processes. Support and User experience of a project can quickly be integrated into the process so that the error becomes a routine exception test, rather than a support request.

Self-Describing Processes

Most ORYX processes are self-describing – by designing projects in granular steps, it is always clear what steps comprise a process, and relatively easy to determine what each does.