Digital Integration Management - looking for examples of mapping incl. ETL/ESB

[Tom Sienkiewicz]

Hi Everyone,

I'm looking for some examples on how to map digital integrations, especially if they involve any ETL process or an ESB in the middle (e.g. ServiceNow-APIM-SAP). I would like to better understand the following implications:

- What is the provider/consumer app and what would be the respective interfaces

- how does the middleware/ETL fit into this picture?

- What if I want to raise incidents/changes against the middleware/ETL? Should it then be also set up as a Business App/App Service? Otherwise, can the Digital Integrations be rationalized in any way e.g. based on number of incidents?

Happy to hear your thoughts on this or if you have any visual examples, that would be great!

Cheers,

Tom

[Bruno De Graeve]

hi Tom,

Let me try to find some answers for you. As you probably know, Digital integration Management rather documents the WHY and not the WITH WHAT. Therefor, we will document the holistic view but not how every element si related to each other. That's for the CMDB to document the operational aspects.

Looking at your example "ServiceNow-APIM-SAP", I see two options based on use cases:

a) ServiceNow provides the data to SAP

b) SAP provides data to ServiceNow

Imagine situation a). ServiceNow will be your Provider Business Application and has one or more Digital Interfaces (f.i. share ticket data and related attachments). SAP's APIM can be set as the Middleware and the SAP solution as the Subscriber Bus. App. Optionally, you can also list the SAP's APIM  as the Subscriber Digital Interface as it acts as an interface to the SAP app. The latter works in a pull-push setup.
In scenario b) where the SAP solution provides the data, they act as Provider Business App and APIM as Digital Interface (and Middleware) where as the ServiceNow platform is the Subscriber. If ServiceNow pulls the data, there's less need to define a Subscriber Digital Interface.
The Middleware on the Digital Integration, should be seen as which Middleware/gateway type should become part of the solution. Not exactly describing how that is setup. here you can use the linkage between the Digital interface and the API CI classes. 
We do have in our backlog that one should be able to select multiple middlewares like SAP's APIM combined with CI.
Another way to document the Middleware, is via an Integration Pattern, that's a concept we'll introduce in the future (safe harbour).
As you can document your middleware artefacts as CIs in the CMDB (f.i. as API classes: see Nick's post on that topic), you can raise incident/changes against them.

We do have plans to introduce an instantiated object of the Digital Integration into the CMDB (similar idea as Business Application vs Application Services) but that's not available yet. We still request some customer feedback what we should document on the instantiated CI which is different than the Digital Integration (apart of the Environment field).
I hope that helps a bit ?

[Tom Sienkiewicz]

Thank you Bruno, that does help to get more perspective on this topic.

Maybe I'm trying too much to have the design and operational layers reflected 1:1. the API class is currently my proposed method for handling ICP tickets for middleware or other interfaces, looks like you also recommend that, makes me think I'm on the right track.

Cheers!

Tom