Integration Process Flow

The Integration Framework provides an open architecture for passing messages into and out of the system in a multitude of ways.

Although integration can be set up in many ways, one of the more common scenarios is explained in diagram below:

In this scenario we have bi-directional integration between an external ITSM ticketing system and ActiveControl. This gives a direct link between the ticketing system and the underlying technical changes that make up the business change. So, whether looked at from the perspective of the ticketing system, or through ActiveControl, there is only one version of the ‘truth’ for all changes across the landscape.

From a more detailed perspective, we can look at the integration scenarios:

1. Once a proposed enhancement or defect resolution is approved and a system change is deemed necessary, the external system creates a Business Task in ActiveControl representing the change. The ticket in the ITSM system and the Business Task are then tied together for the remainder of the process
2. The creation of the Business task in ActiveControl marks the start of the development process. The Business Task can be allocated to a developer who then performs the development and/configuration, and completes unit testing.
3. Once the developer has finished their work, they release the technical change (the transport) and the development team lead is notified by ActiveControl and approves the change. ActiveControl will automatically run a number of configured analysis checks at this point to ensure the change is OK to move on in the process.
4. The change is imported into the Quality Assurance system (maybe after another approval from the Testing manager) and is now ready for testing.
5. ActiveControl updates the status of the ticket in the ITSM system to show that it is now in testing or ready to be tested.
6. Test collateral and results can be added to either the ticketing system or ActiveControl and the ITSM system automatically updated.
7. CAB approval is sought and General/ShiftLeft analysers are run in real time to report dependencies between changes and the impact of different approval scenarios.
8. Once approved by CAB the status of the change in the ticketing system is updated and the change is imported into the Production system at the appropriate time
9. The ticketing system is updated to show the change has been implemented.