Interfaces as separate CI Object between Business Applications/Application Services

[Frank Eck3]

Dear community,

looking for a solution for reflecting the interfaces relation between two Business Applications or to be more précised Application Services.

Here an example, you have let's say ServiceNow and Jira which are connected via let's say Mulesoft for the Incident Process. So in a graph you would have a bi-directional Relation between ServiceNow and Jira via Mulesoft.

That I can build relations between Business Applications and Application Services I know, so I could connect Mulesoft to ServiceNow, Jira and more, but is that the good practice way?

I even want to document attributes and technical settings on those kind of integrations for later usage. Any ideas?

Best regards,

Frank

[Stig Brandt · Accepted solution]

Hi @Frank Eck3 

I think this post is covering your question : Modelling of application interfaces - ServiceNow Community

My view for a simpler solution is that you define - technical services (Interface) - depending on Mulesoft - and the link these dependencies in the Service Portfolio View.

[Stig Brandt · Accepted solution]

Hi @Frank Eck3 

I think this post is covering your question : Modelling of application interfaces - ServiceNow Community

My view for a simpler solution is that you define - technical services (Interface) - depending on Mulesoft - and the link these dependencies in the Service Portfolio View.

[Tobias]

Hi Frank, 

You might find answers in these threads. We have a custom class to handle integration scenarios, allowing for more description to be added than just 'send - receive data', also support, ownership etc. 

How to model integrations/interfaces within CMDB? - ServiceNow Community

Where do folks see integration and broker service ... - ServiceNow Community

[Bruno De Graeve · Accepted solution]

Hello Frank,

ServiceNow intends to release "Digital Integration Management" as a Store app on top of APM. The release should take place in February 2023 (safe harbour, this can be subject to change) and will be supported for the Tokyo and Utah releases.

Use case:

Enterprise Architects, Business Application Owners, and Solution Architects need visibility to integrations between business applications

•The increasing commoditization of applications and promotion of microservices architectures has resulted large increase in the number of applications and proliferation in how they integrate that’s difficult to understand and manage at scale.

•With little to no governance to connect applications, and lack of documentation to track how and why these Applications interact, production issues are hard to troubleshoot and the pace of change grinds to a halt while potential impacts are chased down.

•IT organizations need a better approach to understand integrations required given data sovereignty rules, and new legislation being passed requiring organizations to track and manage information flow across their organizations and externally.

•Declaration and governance over the use of Interfaces can be of great benefit for SecOps teams who are concerned about API attacks for both API’s that are internal or externally facing.

It will introduce the following objects:

Digital Interface and Digital Integration

•Digital Interface:

–Digital Interface are usually provided by a Business Application, but can also stand on their own (for examples in cases of serverless architecture).

–Provides a way for other Business Applications to interact with the Application that provides the interface

–Contains Meta data about the interface including: Name, Version, owners, protocol and more.

–Contains a list of all the integrations that are using this interface

•Digital Integration:

–Represent the integrations between 2 business Applications.

–In a typical scenario there would be a consuming business application, a provider business application, and an interface that is provided by the provider business Application.

–Contains meta data on the integration including: name, version, type, data flow direction, Middleware used, owners and more.

–An easy form enables creation of a digital integration from a single page, including introduction of a new digital interface if it doesn’t exists.

–Once a digital integration is created, a new CMDB link is also created between the two business applications with the type of (interfaces/Interface by). This link enables seeing the integration as part of the node map for any business application

–A new catalog entry is provided to request an approval for a new digital integration. Once approves, the integration would be created.

Model:

a) Business Application --(related list)--> Digital Interface(s) --(referenced by a )--> Digital Integration <--(reference to)-- Business Application.

b) Business Application --(CI relationship: Interfaces::Interfaced by)--> Business Application.

In this first stage, the focus is on the Design aspect of Interfaces (high level description of any sort of API) and the Digital Integrations describing why to Business Applications exchange data with each other.

[Tobias]

Hi @Bruno De Graeve 

This is really interesting.
Do you see 'Digital interface ' and 'Digital integration' as technical CI's that can be used for e.g. incident and change? Or do they sit in the Design domain together with Business Application? 

Thanks