all right let's go ahead and get started uh I said good morning good afternoon good evening to everyone joining the call Welcome to our webinar on digital integration management how you can manage apis and Integrations with apm's digital integration management solution all right there may be some forward-looking statements in this webinar so just want to make people aware of that and we want to give you the opportunity to join us at Future webinars and 360 exchanges uh you can scan the QR code on the screen to see the schedule and there will be a link that will be provided in today's chat for you to sign up to our future sessions all right just a few housek me items we have saved time at the end for Q&A uh you should see a Q&A button at the bottom of your screen uh that will allow you to go into that inter face and ask questions uh you may get live answers uh during the course of the webinar uh but like I said we have saved time at the end so that anything that doesn't get answered uh during the uh during the webinar will be answered at the end um we will also be recording this presentation and sharing it on service now community so either if you have colleagues that would like to see it if you'd like to share it out to other folks or it's something you want to review it will be available and then after the event you will be prompted to fill out a short survey so and we really appreciate your feedback uh if you'd be able to provide it all right just a few introductions my name is Rob Ericson I'm a principal product success manager with service now in our strategic portfolio management area and I am joined by Mark Casto who is also a principal product success manager in SPM and also our uh preeminent APM expert on the team hey everybody thanks for joining us today today all right and we do have uh a poll question to start out here uh first just to find out are you managing a catalog of apis and microservices today so ask if you uh provide your answer to that uh whether you are or or are not doing that and basically just kind of from the uh the specifics around if you are managing things and we'll give another minute or so for folks to answer that question and we're seeing a good spread of answers uh a lot around B and C I think is where we're seeing the primary answers yeah and that's been our experience u in working with customer and actually experience over the years as well okay I think uh we're good there can go ahead and end the poll and share the results so yeah it's very interesting we see a very like an exact spread from a d& but then the majority B and C yeah all right all right thank you for sharing with us all right so here are the objectives of today's Workshop so it's our hope they'll have a knowledge and material to utilize apm's digital integration management solution so here are some some of those steps uh first where our interfaces apis and Integrations who owns them and what do they do how you can build a catalog of your interfaces and Integrations and manage them in service now APM and then managing the design level Notions of digital interfaces integration and tie them to operations aspects and with that I'd like to pass things over to my partner here Maro to talk about digital integration management thanks Rob so welcome everybody uh we want to talk about apm's digital integration digital interface Management Facility and um thinking back to the poll and and what we were looking at there there's clearly in need these the digital Integrations are incredibly important as a part of our our it Enterprise so we've created a design level capability to to build and manage that catalog and next so why does this matter what you know why why did we do this why why do you need it so microservices web services Integrations they're there it's the connective tissue it's the the the Bloodlines between all of your Enterprise systems it's how we architect our systems nowadays and if you don't have a practice of cataloging these and understanding where they are what they do who owns them how they're constructed how do you manage it you can't you have you have chaos you are creating duplicate apis you have apis that are critical but you don't know where they are and who owns them you don't know what they're doing so that if they fail you don't know why something's gone down again it's all of this risk mitigation to understand where your things are how they're constructed and understand it in the context text of not just the individual micros service but understand it in the context of these Enterprise systems that are using them how they interconnect so quite often what we see companies are documenting in a design doc so um jira users you'll have Confluence and your developers they go out and they do their design docs and Confluence they got stories and they go build it and it does what it does you cannot analyze a Word document you can't track and and rationalize you can't do there's so many things that you cannot do with just a bunch of words yeah you could put ji against it and try to drive some sort of Statistics but that's kind of nuts set it up so that you have a formal consistent and analyzable catalog of your crucial Enterprise assets these microservices these apis and what we're doing with with digital inter digital integration management is design level we want to identify ownership business criticality we want to capture architectural artifacts so design documents we have a way to do it if you do them over in Confluence we got a way just to associate it so everything's tied together we're not saying you have to build those artifacts in service now um though in the future we will have modeling tools to help you do so but we capture those artifacts and other such non-discoverable type metadata so that you have a clear picture of what these things are okay great uh so I'm still a little confused though uh within service now what's the difference between a digital interface and a digital integration so digital interfaces we needed a generic term so API that really is a contract a application programming interface that's just saying there's a contract a particular API could manifest in many different ways it might have a Json version XML version it might have a rest version and a soap version and so API was not a good name it's an interface it could be as complex as you know soap rest type apis um those sort of you know modern service level architecture service oriented architecture or it could be old school it could be a system that generates a comma separated file ships it over to a file share and then other applications pick up pick up this this CSV file so we accommodate generically the ability to provide an interface for data going outbound or data coming in it doesn't have to the the direction is specified as we'll see down at the integration level the interface is the mechanism by which information data process whatever can be communicated in transfer so by the way it's not limited to just data although that's probably the most common but there could be proc process level apis process level interfaces kind of things we're capturing versioning ownership functional protocol call message format off architectural artifact um we're coming soon we'll be able to show the information objects we already do information objects on integration and then CI alignment to the actual operational classes if you're not familiar there are some new CI classes in the cmdb starting with CM dbci API just represent apis and then there's a set of other classes in cmdb represent the structure of the actual discoverable deployments of of apis digital integration is a subscriber it it is the one that is utilizing this digital interface we cover much of the same stuff but the functional is a little different data flow Direction triggers schedules response interaction type middleware those are the kinds of things that we capture on the integration because an API could be consumed differently per integration there might be multiple ways to get at it and that's part of what we're expressing also there's the business impact of the criticality to the consuming system remember this is a kind of a consumer side concept then of course architectural artifacts information object representing the information is exchanged CI relationships when you create a interface and it's tied to a business application and you create an integration it's tied to a business application under the hood we will automatically create a dependency line between the two business applications so you see it um digital interface digital integration are not CIS but you do create the relationship so that you have it okay well that's that's a great uh segue into my next question so what is the relationship between these digital interfaces and Integrations and business applications in APM so first off we made a conscious decision that digital interfaces and Integrations do not have to be Associated to a business application they don't have to but it probably makes sense is these Enterprise systems that are represented by your business applications they're either providing or consuming these interfac es and and or they manifest the integration and you want to know how it hooks up but if you're goal is to first catalog everything or perhaps you have hundreds of Integrations and you just want to get them captured you're not concerned yet with how they're being used or perhaps you're going to capture that at the operational level we don't require you to do so if you do so the data model allows you to define a digital interface at both the providing and subscribing business application and sitting in between is what we call the digital integration we're going to show you a picture of the data model in a moment so this allows you to the point is is we want to make sure that you have the capability of not in the past we often will see people and and we've even prescribed it you would create a business appli for a micros service we don't want you to have to do that anymore this is a better alternative and it does have some great first off it keeps your application countdown and um if you're on a per application licensing it keeps your license costs down so it is a better way to do it and it really is more expressive of what we're doing what we're modeling remember we're modeling our world with APM we're modeling the top the conceptual side of it but I hope does that help Rob absolutely thanks all right so digital interface here's a screenshot we're going to do a demo in a moment show you but it's pretty simple straightforward got numbers we got versioning we got life cycles we can identify the software model for the um the um integration software that's being used um we have the providing application type of interface and parents so you can have a hierarchy of apis you might have a parent and then it would have multiple children serving different purposes or maybe they have different different means by which you access them and and that um we'll look at the the actual um attributes here when we do the demo and then obviously at the bottom you got a list of subscribers digital Integrations you also have those child digital interfaces and then finally architectural artifacts which hopefully you're all aware we're using that everywhere it becomes a formal way for Enterprise architecture and solution architecture to put a process around the design level of things if you require certain artifacts to be like a design document some sort of security Compliance Document that sort of thing you capture those and you can manage the architectural design level of these interfaces next please digital integration again it's the consumer we have uh numbering so that there's a u kind of a universal friendly ID um we have the providing digital interface that's the API microservice whatever it might be we have the providing business application those are again are pulled by by that Associated It's associated through the interface if you have a subscriber side digital interface it would be identified there and then finally we have the sub subscriber business application so again those are optional you can see they're optional fill in what services do of course with anything in this you want to be consistent in how you model it so that all the records mean the same kind of thing and we also have typing these are a process integration data integration and we have a variety attributes ownership that business impact then the functional and then finally architectural artifacts again and information objects next if you would so here's kind of a su summary um it's not a real ER but it's more of a summary of the data model business application again it's optional here we have on starting on the left we have digital interface coming in may you see down in the orange the API class we're going to have a one to mini connection from a digital interface which represents the design level we're going to be able to connect to those those API classes that represent real instances real operational view of the API is manifesting there's also application service infrastructure that makes up an API is still aligned via the application service and that little relationship shown between application service and API is not formally prescribed yet by csdm we expect it to be but it makes sense I have a deployment a deployed stack it's an application service and one of the facets of it is the API coming off of it but the app service still is where you map your infrastructure to whatever it might be um we've got links for all this operational stuff I don't want to spend a lot of time there today but the big point I want to get across is we're tying the whole model together coming in August we're going to be able to tie in DLC component which represents the configuration that drives that gets deployed to create that API so some of these down especially at the operational level could change but across the top the things in blue and teal that's the core model digital interface to digital integration another digital interface to business application the subscriber digital interface is optional as are the business application on each end okay this is still a little bit confusing I think to conceptualize it do you have some examples that we could uh show sure Rob let's let's walk through a couple so um go ahead and hit next so we got the idea of we have a business application service now um and really this is workday so here at service now we use workday for managing our employee profiles requesting time off that sort of thing and so service now and pretty much all the other applications in the in the company need to pull that employee profile data so service now has an integration active directory is going to have a dependency on it um other is going to have a dependency on it so workday has a digital interface service now has digital interfaces is um integration Hub and then we create the Integrations and here you see the same pattern over and over active directory has particular interfaces for consuming and inputting data the integration is shown there in the middle but in all these cases we are consuming that digital interface that API that workday publishes for consumption next so here we have general ledger so we have accounts receivable we have our general ledger accounts receivable needs the general ledger um accounts in order to to do its business so it's got an API um go ahead and click through there Rob just make everything show up um so digital we have a digital interface from general ledger accounting for accounts receivable accounts receivable also has an API or an interface for consuming that data it also has an interface to consume sales and marketing transactions so that it so that we can go out and do the collections here we've also modeled the um I think there's one more click try yeah there we go um cou one more there we go now it's lining up sorry about that we didn't quite get our animations done right so the um the accounts receivable here we're showing how that new operational view might line up accounts receivable business app has its production instance it's got apis for consuming general ledger and also for consuming um the sales information and then we see that the apis are each tied to um to the digital interfaces next and go ahead and click on through till it all shows up so this is another just really simple one service now cmdb um the people that are involved with service now op itom operations working with cmdb and Discovery it's pretty familiar you might have tanium you might have secm and that's where you bring in your Microsoft and your Apple based System Info we've got integration Hub again and the IR which are there to consume that information logically cmdb is consuming tanium it's consuming secm but here's a set of Integrations that illustrate it we don't show the um operational aspects of it but that hopefully it makes sense what we're doing um that's that's our model know those those examples really do help um but yeah maybe uh next you could bring us through a demo sure switch the screen here and here we go so I'm just it is evident digital Integrations and digital interfaces show up in Enterprise architecture workspace they're found in the portfolio section we're not seeing your screen yet uh Mark oh okay much better sorry about that okay so digital integration digital interfaces are seen in Enterprise architecture workspace that's our One-Stop UI for every APM nowadays but also it's also here under avocation portfolio management application portfolio digital interfaces digital Integrations two tables that that um provide the the capabilities for us so here I have a digital interface so I kind of start at that API or microservice level I know I give it a name um it's assigned a number I can put versioning information I have the standard csdm uh life cycles even though this is not a CI we're adopting csdm life cycles we have um the middleware use model ID is actually the middleware interface type open um meaning that would anybody could consume it uh a partner that's a B2B type um integration and then internal only meaning it's just for powering internal systems um that can be expanded I've seen some some changes there again they can be a hierarchy of these interfaces or apis ownership who owns it on the business side it side supported by individuals supported by group functional sort of protocol where soap ldap FTP Etc message format Json XML CSV Etc authentication auth authentication type basic off certificate ldap Etc and then authorization type SLE token ooth tokens Etc and then finally at the bottom our subscribers the digital Integrations child apis or digital interface and our architectural artifacts so driving into a digital integration again this what this is representing is this application attendance payroll management system is consuming via moft and the MU soft API the HR self-service system is providing some data for attendance and payroll so the provider digital interface that was what we were just looking at moft there's the business app that was providing it I don't have a subscribing side digital interface but if it existed I could model it and subscribing business application that's my attendance again the type data integration process integration user interface integration could be all of these um I see this get extended quite a bit in the field to to represent particular types again versioning csdm live cycles and um if there's some business unit level ownership we specify the business unit here down here in functional the data flow Direction outgoing incoming bidirectional trigger is it manual is it scheduled process driven event driven if it is scheduled what's the schedule respond respon synchronous asynchronous interaction Pub sub guaranteed message Push Pull and then again the middleware and finally our architectural artifact and the information objects just to reiterate information objects is also um I believe it's in the May release is going to show up over on the digital interface so on the interface that would be the the whole set of information that is presented by the in interface the API this would be the subset of information consumed by this integration all in all this is a pretty simple model when you create these if we go into one of these business applications and we go to dependency View you see I have HR self-service I have a tenance and payroll here is that interfaced by interfaces autocreated CI relationship so that way dependency gets picked up here at the design level um it makes for a nice view uh actually we've got our cdb classes thank you for reminding me so I wanted to call this out again I mentioned it a while ago back in um September the cmdb team and and the platform data team released a new set of CI classes um for apis um it's documented up on the community there will be we'll be providing links to that but if you go look for the the cmdb basically what you do is you update your your core cmdb class classes and you'll get these API packages we'll have a replay of this later this year as we improve and extend our interaction with these CI classes but I just want you to know um that they're out there next all right all right so before we get to our questions we did want to mention that we do have a couple other resources uh out in the world so in our there's a community post that describes the use cases and custom implementations uh that led to digital integration management and we're going to have a what's new uh post on digital integration management available out on the community yeah and we will also Rob and I will be publishing another article it's not there yet but we'll get a link when we post this document we're going to add a link to it um hopefully get it done next week we'll have a new uh post take you know watch out for it in the APM community Forum um which will meant to be kind of everything digital integration management thank you very much Mark that's a great job answering all those questions that came in uh did want to just point folks to some additional resources we have um obviously we've got our service now impact team that's that's out there uh learn more on their Community got training and certification so again here's a link to our training and certification guide and then finally uh experts Services is available and they have a community to potentially help you um be successful in your implementation of APM and digital integration management all right so just want to thank everyone for your time there will be a brief survey that you'll receive uh afterwards we really would appreciate if you'd be able to fill that out let us know how we can do better with these or what what you think went well and as I mentioned any questions we did not answer live we will be posting uh a community post that will then uh we'll we'll uh uh submit those answers and post answers to those to those questions as well all right thanks everybody and have a great day great day