Presentation from Cherwell Global Conference 2018 (CGC) - Topic: eBonding with Cherwell Service Management (CSM) on how to integrate Cherwell with other ITSM systems. This covers the Process and Technology elements of integrating Cherwell with systems like ZenDesk, ServiceNow, Remedy, Jira, Azure DevOps (VSTS), TFS, ConnectionWise, and others. This is the abbreviated presentation actually shown at the CGC - the full version is also available on SlideShare.

1. eBonding with Cherwell

2. Rick
Muñoz
• Chief Architect at T4S Partners, Inc.
• Cherwell Certified Engineer,
Microsoft Certified Solutions Expert:
Azure
• Specializes in System Integration,
Cloud Migration, and Application
Modernization solutions
• 25+ years experience in IT,
Enterprise Systems, and Advanced
Technologies

3. Defining eBonding at
the process level
PART 1
Rick Muñoz

4. 1. eBonding (ITSM-to-ITSM)
2. Business Apps & Process
3. On-Premise Automation
4. Cloud Automation
5. System Management
6. Asset Management
7. Monitoring
8. Security & Identity
Integration with Cherwell
eBonding
Monitoring
Asset
Management
System
Management
Cloud
Automation
On-
Premise
Automation
Business
Apps &
Process
Security &
Identity

5. • eBonding – or ‘electronic bonding’ is the process
& data integration between similar or overlapping
business applications
• eBonding in ITSM creates bi-directional process
synchronization of incidents, service requests, and
other artifacts between to ITSM-focused systems
• eBonding streamlines coordination of “ticket”
reporting & handling between 2 or more ITSM
systems within or between organizations
What is eBonding?

6. Examples
ITSM/PSA systems: ServiceNow,
Remedy, ConnectWise,
Ubersmith, ZenDesk, …
ITOM systems: ScienceLogic,
uCMDB, …
Development tracking systems:
VSTS/TFS, Jira, …
Release, Change, & Deployment
Systems: Jenkins, SAP ChaRM, …
• Elimination of “Swivel Chair integration”
• Mergers & Acquisitions
• Customer/Partner that wants to interconnect
• Outsourcing service desk
• Help Desk consolidation
Common Drivers of eBonding

7. ITSM ticket eBonding
• Cherwell <-> ServiceNow
• Cherwell <-> ZenDesk
ITSM Change & Release Mgmt
eBonding
• SAP ChaRM <-> Cherwell
• Cherwell <-> Jenkins
Examples of eBonding in ITSM
IT Operations Management (ITOM)
eBonding with ITSM
• ScienceLogic <-> Cherwell
• HP OpenView <-> Cherwell
DevOps eBonding with ITSM
• Cherwell <-> Visual Studio Team Services
• Cherwell <-> Jira

8. • Use Cases
• “Hand off” of tickets to other teams
• Gain Visibility in Cherwell of tickets from other
systems
• Synchronize tickets between company ITSM
system and external help desk provider
• Autoticketing and updating status
eBonding – real world experience

9. Clear ownership “handoff”
• What system sends
email to whom?
• Which system waits the
“3 days” after resolution
• How does the
classification in one
system show up in the
other?
Example of eBonding: Simple Incident Lifecycle
eBonding Integration
Company CSM
Help Desk Provider
ITSM system
User
submits
ticket
Help
Desk
Triages
Ticket
Reflect
assignment &
status change
Assigned
& In
Progress
Assignee
Works
Ticket
Assignee
Resolves
Ticket
CSM
system
reflects
resolution
+3 Days after
Resolved
System
marks
ticket as
Closed

10. Ownership can be given
or taken by either side
More Complex Example: Ownership can change in-flight
eBonding Integration
Company CSM
Help Desk Provider
ITSM system
User submits
ticket via Portal
Help Desk
Triages Ticket
CSM system reflects
assignment & status change
Assigned
& In Progress
Assignee
Works
Ticket
Assignee
finds out
assignment
& ownership
taken
‘back’
Internal
IT team
takes
assignmentAssigned
BACK
Help Desk
has
to reassign
ticket
Reflect
Change
Chg
Priority
Work
Ticket
Internal IT team
has to determine
internal assignee
Reassign
Back
Assign back
with new
Classif.
Assign –
NEW SLA!
User
Reopens
Ticket
WORK RESOLVED
Reflect Change
CLOSE
?

11. Lifecycle Status
Steps can vary
between both
systems – in both
allowable status
changes and
requirements of
each status
Impedance Mismatch of Statuses
eBonding Integration
Company CSM
Incident Status
VSTS
(OOTB)
NEW
NEW NEW
(with
assignment
field filled in)
Ready Closed
New
Assigned
Active
In Progress
Pending
Resolved
Resolved Closed Reopened

12. Status definitions
and sequence of
“work items” vary
between their types
in VSTS
Status transitions
work differently in
VSTS than in CSM
Example of mapping process status

13. Transition Points between processes
mapped and coordinated
Transfer of incident/SR ownership
and control must be fully agreed
upon
Differences have to be accounted for
Detailed USE CASES need to be
defined!
Process mapping

14. Mapping may require connecting at a semantic
level: Service Catalog, Priority/Urgency/Severity
Some fields require common or shared
information: Customer/Requestor, Team, Assignee
Technical field mapping may require type
conversions or even value transformation
Mapping fields across the process
Web Method
Parameters Required Conditional Value
X token X Constant = "Hujkf;KqC"
X partnerPrimaryReference X Incident.IncidentID
X partnerSecondaryReference X Incident.IncidentID
X status X Incident.Status
X impact X MAJOR|SIGNIFICANT|MINOR
urgency X HIGH|NORMAL|LOW
X shortDescription X Incident.ShortDescription
X affectedContact X Submitted on behalf.RecID
X assignee X Incident.OwnedBy
X assigneeGroup X Incident.OwnedByTeam
X expectedStartDate TBD
X location X Incident.PC#
X requester customer.RecID
X extraFields.CustomerTicketType Incident.IncidentType
X extraFields.Service Incident.Sevice
X extraFields.Category Incident.Category
X extraFields.SubCategory Incident.SubCategory
X actionType X Constant = "Update"
additionalComments Journal Entry
N/A accountableGroup
N/A accountableOwner
N/A classification
X closureDetails X Incident.Close Description
N/A configurationItem
N/A contract
submitSyncIncidentRequest

15. • Who initiates Incidents or Service Request (or other)?
• Who owns what when?
• Are the processes aligned? Where do they diverge?
• What can change after assignment?
• Where do process and object dependencies, including
validation & requirement rules, differ?
• Where do the systems need to use the “same” data?
Key Questions

16. Find the simplest
eBonding approach
that’s of value to
minimize the complexity
that needs to be addressed
in implementation
Clearly define the patterns
& ‘recipes’ that will be
applied in eBonding
Finding the lowest complexity acceptable
Lower Complexity Medium Complexity High Complexity
Primarily a one-way
ticket ownership
transfer on-demand
or automatically
Two-way transfer of
tickets based on
agreed-upon rules
Two-way
replication/sync of
all tickets
Basic updates sent
back to originating
system
Basic updates sent
back to originating
system
Complex mapping of
service catalog
Limited scope of
tickets/classification
Clear ownership of
tickets by only one
side
Major process &
data differences
Same common data Either side can own
and process any
tickets in any state

17. Implementing
eBonding
PART 2
Rick Muñoz

18. • Differentiate between Direction of connection initiation and
direction of data & process flow
• Best: Both systems Push to the other
• If only 1 system can be changed/extended, that system will be
responsible for pulling & pushing data
• Direction will often depend on availability of interfaces or
integration mechanisms
• There will always be latency between the two systems
Implementation foundation: Direction

19. Technical
integration
can be
achieved in
multiple
WAYS, each
with
tradeoffs
Example Integration Implementation Scenarios
A sends email to B B sends email to A
A connects directly to B’s
API to push data
B connects directly to A’s API
to push data
A connects directly to B’s
API to push data & poll/pull
data
B connects directly to A’s API
to push data
A detects changes and
processes them
B detects changes and
processes them
Integration Platform Pulls and
pushes to each A and B
A pushes changes to
Integration platform
B pushes changes to
Integration Platform
Integration Platform pushes
changes from one system to
the other
Email-only integration
Two-way
Push
One-sidehandles
integration
Intermediary
Controller
Intermediary
Messenger
A connects directly to B’s PI
to push, poll, pull data; may
be invoked by notification
B notifies A via email or webto
pull new/updated data
One-Side
integration w/
notification
ITSM System ‘A’
(typically CSM)
ITSM / Ticketing
System ‘B’

20. • Futureproof the integration: Design for Changes in
process & field mapping
• Instrument all interactions: Detailed logging and
tracing is essential to diagnose & resolve complex
sync issues
• Consider flexible technical options: Leverage
integration beyond point-to-point
• Look for the simplest solution to start with: Full
sync will bring high complexity
eBonding Lessons Learned

21. Visibility into eBonding
• eBonding will have limits – Visibility is key
to see, understanding, and address those
limits

22. • Cheap & Quick eBonding approach: email
• Establish foundation for multiple integrations with
integration platforms and tools
• Define your own eBonding “connector”
• e.g., MSPs to customers
• Company to supplier
• “Standardized” Integration & Interface
• Leverage the “Canonical API” in Cherwell
Further considerations & options

23. • Process mapping
• Process flow & ownership
• Lifecycle & Status mapping
• Technical Integration
• Synchronous vs. Asynchronous
• Latency considerations
• Pull vs. Push vs. Polling – who
establishes connections &
ebonding logic
eBonding is more than just copying tickets
• Direction of eBonding logic & data
• Field mapping & handling
differences
• Data mapping Customers,
classifications, users, priorities,
etc.
• Partial vs. Full synchronization
• Depth & Breadth of eBonding
• Single to multiple processes
• Objects, attributes, &
relationships

24. • eBonding requires Business Process integration, not
just technical or data integration
• eBonding will always be Hard and often very
specific to the systems
• No two ITSM system are configured the same –
even two Cherwell systems
• eBonding requires close monitoring, ongoing
operational support, and continuous refinement
eBonding Reality Check