Taking the Trouble Out of Ticketing with ServiceNow and AWS Support APIs

By Farook Babu, Cloud Delivery Leader – DXC Technology
By Jim Boling, Integration Product Owner – DXC Technology
By Peter White, Integration Product Architect – DXC Technology
By Dan Hattrup, PhD, Customer Solution Manager – AWS

DXC Technology

A fundamental component of the Operational Excellence pillar of the AWS Well-Architected Framework is evolving your environment, incorporating continuous improvement over time.

Moving to the cloud should be transformational for a business, by adding agility, and making it easier to innovate. It’s important to remember the innovations are often small, incremental in nature, and designed to solve a “legacy” problem from an on-premises environment.

DXC Technology, an AWS Premier Consulting Partner, identified one such improvement opportunity—by integrating DXC’s ServiceNow instances with AWS Support, the global IT services company automated ticket processing to accelerate incident resolution.

DXC serves more than 6,000 customers in 70 countries, and as an AWS Managed Service Provider (MSP) DXC needs seamless integration for ticketing, support, and two-way communication to provide world-class customer service to clients.

The guiding tenets for this work focused on the Well-Architected Framework—incorporating design principles such as performing operations as code; operational health metrics such as time to close a ticket; and the aforementioned evolution.

All of this allowed DXC to simplify work for customers inside and outside the organization. An added benefit for DXC is that the API-driven integration to AWS Support contributes to the AWS MSP audit and review.

This post explains the previous environment, the old customer service workflow, and how the work was done to integrate ServiceNow and AWS Support. Finally, we’ll share the successes DXC achieved within the current environment.

Pre-Integration Architecture

As a service provider, DXC frees up customer resources from platform work through automation, managed services, and environment provisioning. These services enable DXC customers to focus on higher value work in the application stack.

The AWS Well-Architected Framework identifies various models of separating responsibilities between the end customer, a service provider like DXC, and AWS. The different models require support interactions between the three entities to varying degrees. In our current situation, AWS is responsible for the platform, DXC provides managed services, and the client focuses on their business applications.

AWS refers to this as a Separated Application Engineering and Operations (AEO), and Infrastructure Engineering and Operations (IEO) with Central Governance and a Service Provider model in the Well-Architected Framework. The support structure is detailed in Figure 1 below.

Figure 1 – Separated AEO and IEO with centralized governance and a service provider.

The end customer is responsible for the blue area in the diagram above, while DXC is responsible for the purple area. AWS performs work within the orange area.

If there is a disruption to service availability, customers need to diagnose and remedy problems at the application level, and communicate platform disruptions to DXC. Meanwhile, DXC needs to be able to isolate any disruption at the service or platform level in conjunction with AWS.

The common thread tying this all together is the ServiceNow ticketing system, allowing communication between the three layers as a central repository for incident reference.

Original Workflow Process

Prior to integrating ServiceNow with AWS Support, the DXC operational technicians followed a manual process. Problems were recorded in ServiceNow, and an AWS case would be opened via web, chat, or phone, depending upon severity.

If an AWS Technical Account Manager (TAM) was required, that was another process and conducted via email most of the time. There was little to no automation in this process, and multiple opportunities for failure instead of being a reliable mechanism (see figure 2).

Figure 2 – Original workflow process for AWS Support engagement.

Recognizing there was an opportunity to improve on this process, DXC initiated an internal review, starting with their customer base and working backwards to a solution.

Customers may have multiple AWS accounts, some of which may not be managed by DXC, in addition to those that are. They may also have their own instances of ServiceNow that would require integration with the DXC ServiceNow environment.

DXC narrowed the options to improve the service provision process to the following three:

• Applying Lean techniques to the manual process. While some improvements could be realized here, not enough value would be gained with this approach.
• Use an existing ServiceNow plugin to accomplish the integration; after review of what was on the market, nothing met DXC’s needs.
• Build a bespoke solution that any DXC organization could utilize when needing to exchange tickets with AWS. This solution would meet the needs of the DXC Cloud Operations team, and it was scalable to other teams within DXC’s global footprint.

Integration Architecture and Work

Once the path forward to create a leveraged integration solution was made, DXC created user stories, set out the project plan, and divided the work into two sprints. System integration, and testing was scheduled with AWS Support following those sprints.

Recognizing the variable demand for this solution, the development team based the solution around AWS serverless options, starting with AWS Lambda and using AWS Step Functions to sequence the Lambda stages.

DXC designed an Integration Adapter for AWS Support, utilizing widely available AWS services such as Amazon API Gateway, Amazon CloudWatch, Amazon Simple Notification Service (SNS), and Amazon Simple Storage Service (Amazon S3), among other services. This was done to ensure scalability within DXC’s other lines and business, and to make it replicable via consulting engagements for other DXC customers facing similar challenges.

After the initial build was tested within the DXC systems, the next two weeks were dedicated to testing integration with AWS Support and finally completed with the assistance of the AWS TAM on the DXC account team.

Architecture

The technical solution leverages features of ServiceNow to facilitate the communication. As examples, it uses the Standard Incident eBond Interface as the foundation to build a Partner-Group style eBond (bi-directional integration) between DXC and AWS.

Flows are built in ServiceRamp in the DXC-SP tenant using ConnectNow and the Integration Adapter for AWS as endpoints. This allows for asynchronous communication between the support groups, which facilitates ticket resolution when support groups may be geographically dispersed.

Figure 3 – Service integration framework for support tickets.

Outbound interactions from DXC to AWS are event-driven. Updates made in ServiceNow are fed to AWS in near real-time and translated into “create” or “update” actions performed by the Integration Adapter for AWS against the appropriate AWS account.

Inbound transactions from AWS to DXC are schedule-driven. New or updated cases in AWS Support Center are discovered based on a polling cycle, and are translated into “create” or “update” actions performed by the Platform-DXC Incident Capability inside ConnectNow. The polling cycle is set at a five-minute interval.

New Workflow Process

The figures below provide a comparison of the previous and current processes. In the original process, note multiple manual steps (creating, resolving, closing tickets) and lack of integrated reporting against the SLA.

Figure 4 shows the original unidirectional automated communication (AWS notifications picked up by eBonding, but not the reverse), which meant that work completed by DXC had to be communicated to AWS Support separately. This could lead to delays in resolution, while waiting on updates for troubleshooting and resolution.

Figure 4 – Original Incident Management workflow (manual).

The new process automates creating, updating, and closing tickets based on the status provided by AWS or the DXC CloudOps team. Figure 5 shows the new incident management workflow, including automated ticketing process, as well as bidirectional communication between the teams.

Automating updates allows for services teams on both sides to quickly see the status of a ticket as well as next steps in the system. In addition, automatically closing tickets at resolution eliminates a manual process that adds no business value, but can create reporting issues if a ticket is accidentally left open.

Figure 5 – New Incident Management workflow (automated).

Outcomes and Rewards

After completing this build in late 2020, DXC has applied this ServiceNow automation in daily operations. Through the first half of 2021, there were an average of 40 cases per month, across all severities.

The automated interaction between AWS Support teams and the CloudOps engineer from DXC has helped with greater awareness of issues, regular updates on the tickets, and more accurate resolution estimates. All of the tickets this year have been resolved within the service level agreement (SLA), and the average resolution time is under 24 hours across all severities.

This new platform has led to quicker communication, and easier access to AWS technical expertise, combining for faster resolution for our mutual clients.

Conclusion

The cloud provides opportunities for businesses to be nimbler in how they interact with both customers and service partners. Using cloud best practices allows for faster innovation, and lowers risk when experiments fail, due the ease of spinning up low cost environments.

Automating processes can eliminate steps that do not add value (such as closing out tickets), which benefits the company by lowering the risk of accidental omissions, and can expedite the most important tasks (like troubleshooting, communication).

A simple challenge of “how can we make an old process new again?” led to DXC leveraging best practices, innovating in-house, and greater customer service.

Interested in integrating your ServiceNow environment with AWS Support, discussing how to automate internal support processes, or becoming more agile using the cloud? Learn more by contacting your AWS account executive and AWS – DXC partner team representative.

.

.

DXC Technology – AWS Partner Spotlight

DXC Technology is an AWS Premier Consulting Partner and MSP that understands the complexities of migrating workloads to AWS in large-scale environments, and the skills needed for success.

Contact DXC Technology | Partner Overview

*Already worked with DXC Technology? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.