If you have a specific enquiry, please contact us.

Can the HELIXsystem Process Assembler (HSPA) be used to re-document my existing implementation?

Yes.

The HSPA will capture a complete representation of any legacy architecture and will render this graphically, with an explanatory narrative. This description will be complete, meaning it will represent every execution sequence of every messaging event, and will be unambiguous, meaning it will be of precise meaning to IT consumers and understandable by business users.

This description may be exported to any of the leading process modelling suites enabling it to be broadly socialised across the organisation, and can be exported in PDF format, suitable for distribution to regulators or other external parties.

Does the HSPA require a data sample to be extracted and harmonised? This requires significant manual effort before any discovery efforts can commence.

No. The HSPA continuously monitors all message interactions across all applications. It is not a log-scrapping, data sampling, message extraction technology.

The HSPA automatically creates and associates a Synthetic ID with each message. This Synthetic ID dynamically updates as a message migrates across messaging middleware, enabling a message to to be tracked across a fragmented heterogeneous infrastructure. This is fully automated at runtime and is achieved without altering the messages in any way or requiring any changes to the applications.

Our systems comprised of repeating processes that execute in very large numbers, complex processes that require some form of human intervention and ad hoc workflows that are largely manual.  Can the HSPA map all of these?

The HSPA cannot capture entirely manual process flows. The technology requires some form of system communication for the messaging events to be captured.

Human-to-machine interactions can be captured as there is an interaction between the input point and the system. So long as there is a system interaction, the HSPA will capture it.

We have been tasked with building a register of every application in the organisation capable of moving an asset, together with the rules and triggers that would cause these applications to action a movement. Can the HSPA assist with this?

Yes.

It is possible to extract a register of applications from the HSPA output together with their interfaces. Once all the execution sequences associated with the applications have been identified, it is possible to inspect the granular detail of the messaging events to identify their cause. Diagnostic tooling is provided by the HSPA to assist with this task. Once the register of applications and their associated interfaces has been constructed, this will be automatically maintained by the HSPA as changes are introduced to the implementation.

Is it possible to replay each unique execution path?

Yes.

This is part of the diagnostic tooling provided by the HSPA. Once a unique execution path has rendered into BPMN2, it may be replayed. Play, Stop, Rewind, Fast Forward and Pause buttons are provided to enable the recorded events to be played through, stepped through or individually isolated and examined.

As each interaction is replayed, the BPMN2 diagram is highlighted showing the step in the process being examined and the application(s) being actioned. The HSPA accompanying narrative also updates, showing the number of message event, its direction, the transport being used, its timestamp, and via a single-click, the actual body of the message.

This enables a system analyst to examine the execution path in granular detail, and more importantly, precisely identify the cause of the path.

Can I isolate a particular activity using a number of search parameters?

Yes.

If, for instance, you were interested in examining specific transactional activity, you can search the messaging events by:
- transaction time
- counterparty
- transaction desk
- instrument type
- transaction size
- trader

Should you wish to monitor this activity on an on-going basis, this search could be defined using the HSPA Rules Engine, enabling an alert to be generated every time a transaction meeting the defined parameters executes.

This is particularly useful functionality for monitoring and isolating abnormal transaction activity across fixings, an area of high interest to the banking industry regulators.

We have modelled our processes . Can the HSPA be used to validate these are the processes running in production?

Yes.

The HSPA will produce a representation of the actual processes running in your staging environment. This can be used to validate that what is running in staging, is identical to the processes as modelled.

Following the migration from staging to production, the HSPA will produce a representation of the actual processes running in production, enabling an audit trail from the process models to the actual processes running in production to be constructed.

I've heard that I need a Data Mining solution. What is Data Mining?

Data mining is a methodology developed to identify non-obvious data relationships across aggregated sets of data. It was not designed to identify sequencing relationships across aggregated sets of processing activities.

Data mining techniques are often used to identify process relationships but essentially this is the wrong tool for the job. The HSPA is the right tool for the job and will produce a complete and unambiguous description of every message interaction across any IT infrastructure regardless of its complexity or fragmentation.

Is the HSPA another algorithmic based process discovery tool or an entirely new approach?

No. The HSPA is not a message sampling, algorithmic based process discovery tool. It is an entirely new, unique and patented approach.

Algorithmically derived process models do not translate smoothly into formal process representations due to a number of difficulties including what is described as “Representational Bias” and all algorithmic process discovery tools have some form of representation bias.

Representational bias describes the assumption that all the processing activity being observed can be correctly captured and that all the processing activity correctly captured, can be described. This assumption is often incorrect.

The usefulness of an algorithmically derived process representation is a function of the representational bias of the tool and the type of processes being mined. Representational bias impacts every model generated using this approach with all models being limited to some degree by the bias of the tool.

We already have system monitors. Can we use these or do we need to install the HSPA Collectors?

The HSPA can utilise the existing monitors. All that is required is that these monitors be directed to a repository from which the HSPA can collect the reported message interactions. This is possible as the HSPA is built as a set of inter-linked modules, with the Assembler Utility able to be separated from the Collector Framework. The Assembler Utility, in turn, is comprised of four modules: the MVE Framework, the Time Harmonisation Framework, the Correlation Engine and the Notifications & Alerts Engine.

In a conventional deployment, the Collector Framework and the Assembler Utility are separated by a buffer. Should you already have monitors installed all that is required is that the existing monitors report the observed service interactions to a facility to which the Assembler Utility is able to subscribe. The Utility will pick up the reported interactions from this location and correlate the reported interactions firstly into sets of unique execution sequences before compiling an end-to-end system representation.

We won’t install 3rd party software on our production messaging middleware. How does the HSPA address this?

Collectors are the only component needed to be deployed to a specific messaging environment. We will provide messaging middleware specific Collector source code for you to review, modify & implement as your own software.

We have data located in multiple regions around the world. Some of these regions have privacy laws that prohibit the cross-border communication of data. Does this impact the HSPA?

No. The HSPA is modularised, enabling it to compile a complete end-to-end system representation, even though the captured message interactions may be locally stored. In circumstances where transactional data is not permitted to migrate across geographical boundaries, regional specific HSPA data-stores would be implemented and the data isolated. Such isolation however, does not prevent the HSPA from compiling and generating a complete and unambiguous representation of the end-to-end processing logic.