"Achieved end to end visibility of the business data in the Integration solutions and improved customer satisfaction."

In this case study we will look at a customer who was building an enterprise integration platform with Azure Integration Services. The scenario here is that they were building a number of interfaces to support the new HR system being implemented. There were use cases like new employees being onboarded to the organization, updates to employees and then termination of employment when an employee leaves.

For many applications the user setup requirements can be quite simple for new users and there are approaches like users belonging to Active Directory and Entra ID groups which can enable access and there are technologies like System for Cross-domain Identity Management (SCIM) which can be used to support user provisioning in applications. Even with these approaches there are also many cases where you need a workflow to orchestrate user setup and also integration with 3rd party applications or your own applications where you need to orchestrate their API’s to synchronize users.

In this case the customer had planned to implement these integrations and then using publish/subscribe patterns they would drop in new interfaces to integrate with other applications who needed to be aware of employee changes. Some applications even needed batch files with lists of employees.

The customer had a very interesting roadmap for their integration platform however one of the challenges they had was how to manage all of these integrations for HR, but also for the other non-HR related interfaces.

In the HR team they have a group of users who are experienced with employee setup and configuration and comfortable as super users in many of the applications. The challenge for them is that in a highly integrated solution it’s just too complicated for them to see the integrations which are happening under the hood and they then to raise loads of support tickets for even the most basic troubleshooting scenarios.

The aim for the users was to tackle the problem that 80%+ of the issues they tend to have are data issues in systems and not really problems with the integration process. By giving visibility of the integrations and errors to the business and support users they can triage any issues themselves before problems are raised as a support ticket then take time to get access to a developer who can tell them what the problem was.

There is a huge cost saving to be made in a number of areas:

• Not pulling developers away from working on new projects to support simple issues to fix
• Not taking time to process help desk tickets through the escalation process
• Not wasting time of HR staff coordinating a support ticket to get a user fixed
• Avoiding new employees turning up without access to key systems and then being limited in what they can do on their first days

Architecture

The architecture for these initial interfaces looks like the below diagram showing the flow of data for new hires and employee updates to various systems.

Transaction Modelling

The customer chose to use Turbo360 Business Activity Monitoring (BAM) with the integration platform developed with Azure Integration Services. By adding BAM to the architecture it was intended that key business milestones within the interfaces could be communicated to Turbo360 which are then shared with business users and support operator so they can do self-service.

In order to model the business processes and transactions the customer modelled a structure in Turbo360 as shown below in the tree view. You can have folders and business processes modelled for each of the departments. This allows the customer to create a context for each business unit so users can be given permission to have visibility for the things they care about.

Inside a business process there are 1 or more transactions. The aim here it so create a simplified view of the transaction in a visual designer. The implementation may be in different technologies such as Logic Apps, Power Automate, Functions, etc. The technical implementation may have 30+ actions required to implement the interface but in the case of BAM the user only needs to see a much simpler view of that transaction. In many cases it can be as simple as Started, Completed Successfully, Completed with Error.

Once you have configured the designer showing what you expect to happen then next in your implementation you implement the places where you send these business milestones. In the below example you can see a shape using the BAM action in the logic app designer.

Id send updates where I need to and these will show up to the BAM user giving visibility to the normally hidden away interface.

Message Tracking

With the BAM message tracking feature the customers users can trace messages and see whats being processed. In this case the HR team super users can see all of the employee updates and new hires being processed across the different systems. The business process view can show all of the key transactions within the business process. The team could configure the properties and views that made sense for tracking employee updates.

The HR user can perform a search if they want to look for transactions related to a specific user.

They can also open up the transaction to see what happened as shown below.

In these cases the HR super user can see if an employee new hire was processed successfully of if there were errors they can review them. The most likely issue is that there is some invalid data entered during the new hire onboarding in HR system. They can see errors and correct the data.

Reprocessing

Once the data is corrected the customer also allowed the HR super user to resubmit the BAM transaction themselves. Below you can see a transaction that was re-processed and a new running transaction where the original transaction was replayed.

Previously for every issue it needed to be raised as a support ticket then escalate through L1 and L2 support before anyone with access and experience could review the logic apps and identify the issue and tell the HR team that they had entered invalid data in the HR system which breaks the integration to the target system. The HR team fix the data and then need the integration team to reprocess the message.

With BAM the HR team see the error, fix the data and reprocess the message without a support ticket ever needing to be created in the first place.

Dashboards

To help with creating confidence in the integrations, BAM dashboards were used to help get a flavour of interface metrics like success and failure.

Creating visibility of performance helps users begin having confidence in the integrations they depend on.

Monitoring

Monitoring is important for any integration platform, but going beyond the technical monitoring the customer chose to use BAM to monitor the business processes. In this case there are a number of ways you can monitor such as:

• Look for errors
• Look for interfaces taking too long to run
• Look for interfaces that we expect to run but haven’t (No Data received)
• Custom query scenarios

Below you can see an example of an incident raised for an interface where it is taking a lot longer than usual. In this case you might get an alert so you can check a downstream system isn’t having performance issues which are affecting the interface.

Extending out to other interfaces

The customer’s HR team had a positive experience of self-service integrations and were happy with the confidence they get from having visibility of their interfaces. This created a desire for other interfaces to be built using the same approach. The customer was empowering users at the same time as reducing support tickets.

You can see below that new business processes were created and BAM became a single console for all interfaces.

Extending out to other types of solution

As the customers use of BAM grew in popularity with the business and support users they wanted more visibility of those key processes and automations which they depend so heavily on.

At this point the customer was also able to provide updates from solutions delivered in different technologies but provide the users with a single location where they can get a cross technology view of what’s happening.

The customer was able to send events from technologies like Power Automate where they implement automation processes for Dynamics / Power Platform to BAM. They were able to send events to BAM from their data platform for technologies like Data Factory, Synapse and Data Bricks so that users have high level visibility of data processing processes and where they are up to.

The customer could even have events published from custom applications or IT automation scripts.

The aim was to get a single view of all processes regardless of implementation technology.

Conclusion

The customer was able to achieve their original aim to provide a positive experience to users who depend heavily on important interfaces which are foundational to their department running effectively.

In this case the user experience was so positive that they wanted to use BAM for more interfaces within the department and then that spread outside of HR and other departments also wanted visibility and confidence in their integrations and to be able to self-service their interfaces so they are empowered to get on and do their jobs rather than the integration platform being viewed as a bottle-neck.

The side effect of the self-service interfaces was that the customer was also able to reduce the number of support tickets that the integration team had to deal with and also the developers on the integration team could then focus on delivering new value to the business on projects and there is a reduction in the amount of time developers on the integration team spend supporting interface problems. Particularly those which aren’t really integration problems. In this case the customer is also making a saving of > 1 FTE on the integration team by empowering business users, support operators and other application specialists to self-service their interfaces.