good morning everybody I'm going to go ahead and get us started here and get us up to our content there'll be people logging in for a little bit Welcome to our Digital Services Forum by weekly we're going to talk today about modeling microservices and apis in the csdm this has been a topic that you know Charles and Jason and I have been getting a lot of questions about so we thought we'd bring in some of the experts and then um we have a guest today that's going to be talking about a specific problem there working on with this as well so I'm excited about today's today's content we have a little custom here if it's your first time if you would drop a name inside the uh chat that'll be great we we keep track of that and we go back and look at the logs and let everybody welcome you to the group if it's your first time I I will post a link that'll be inside I do this at every meeting but I'll I'll post this link that gives you access to everything on our community so basically the four things you'll get is you'll get access to the zoom registration also access to our instance access to past meetings and then a YouTube playlist that lets you go back and see any of the prior meetings Okay so that will be in the chat so you'll have that but I want to take you back to one of the sessions just to set some context for our speakers today but um back in December we talked about a road map road mapping our csdm capabilities and um I provided this link inside of the Borum like once we go to The Forum once I post the video I also post any of the content this content we have over a thousand downloads on it so I wanted to bring it up again because it's really relevant to today's conversation what we talked about in this s back in December was that what your modeling really doesn't matter until you can give it to somebody to use it and we talked about all the use cases like the collaboration between a csdm designer whatever your role is doing that and an incident manager the incident process owner or the change process owner or the security process owner or the catalog process owner and so on right until somebody's consuming your models consuming that data to improve a process there's really no value in it so we talked a lot about that here and I I think today we're going to have our speakers and that was what really attracted me to this use case so Richard coming over for a banner and he'll talk about somebody that came to him and asked him for this data they need it for certain processes that they're working on and then Mark will give um because it's around apis and microservices there's some things that we have now that we can do to create models and there'll be additional capabilities in the future so we're going to talk about both of those as we go forward so first we're gonna have Richard set us up he's going to talk a little bit about the people that came to him asking him about the model for their use cases and then Mark is going to respond with again what we have now and what we have later so with that I'll hand it over to you Richard and you can get us started with that problem statement that you talked us I think it was last November that you brought this up so it's great we're getting uh getting you on to talk about it yeah and before I start sharing I wanted to speak to what you just said about value because for a while we were all focused on is the data right is the data right is the data right and keep fixing data and the data kept breaking because nobody really understood the value of what we were trying to do and we've made that that shift back in about November you came out and we made that shift and it's been all the difference in the world we have a lot of Engagement from our it application owners now I've got people calling me wanting in on this right so which is a big difference from forcing people to fill out spreadsheets so anyway I appreciate that John that was very uh great information and and we acted on it so excellent so let me go ahead and share and let's make sure I share the right thing I want to share this one let me know when everyone can see that looks good Richard okay so so what what John was saying is what brought this up was um we had a a conversation I'm going to say back in October with our cyber department and what they were concerned with is being able to track apis and and we actually had a a vulnerability that was discovered through one of our apis it was caught very quickly through our sock um H however they it took them a large amount of time to be able to relate that back to who was using that who built it where is it being stored all those kinds of things and so they reached out to us and go hey we would like to be able to record this we need a CI when these things happen so that we could manage these things on their end and then if you think about it uh beyond that is that today they're they're um they're using a third-party app to do this and there's no integration between that 30 third party app and what what we're currently doing in snow and that thirdparty app is just not scalable for an enterprise-wide um U environment and um so therefore we and nor is it relatable back to actually anything it's just they're seeing apis and and today we're just they're they're struggling with and only able to track those external calls being made through those things and they want to be able to do all of them and at the bottom down here I put I think the time to speak about that right it's we have that same situation with certificates right in certificate management where cybers you know they're they have their own tool for doing that they're doing the best they can but we still have certificates expiring at midnight and we all know the result of what happens when that happens basically we have an app that goes down and now we get every got everybody up at two o'clock in the morning trying to figure out what's going on and nothing really drives anybody towards seeing the fact that that information is missing and it's a simple problem just the CI we may spend hours trying to troubleshoot and look for the problem only to find out well the SE surprise was suspended so uh the other one is the uh we're doing some modeling um I won't say we're doing service mapping yet we're kind of precursor to service mapping but we're doing some application modeling and and in that modeling exercise we're we're in conversations with it application owners we're discovering that well this interfaces with this and then there's an integration here with this and these API calls or there's data shared between apps so that from an EPM perspective that's why we're trying to figure out what's the right way to be able to record that information inside of service now and then as you can imagine from from from a change in incident process perspective there is a dependency on those CIS and when we don't have CIS for search and we don't have CIS for apis it it makes very difficult to track you know they're picking something uh they they other CI being selected because there's no direct CI to link it to so that's another thing that we're trying to solve for any questions about any of that okay so in the in the next slide here let me see if I can get it to advance hang on sorry so in the next slide I'm just showing you an example of what we're what we're talking about here and at the top we have an application called Acuity and I'm sure this is rudimentary for a lot of your folks on this call right but we have a production QA environment for that application uh there's two components that make up that app there's an Acuity connect and an aity acity advanced care and then those uh those are broken down into the smaller pieces where we have a tomcat server an Apache server and a database server that all make up that prod instance of a cuity connect and we have a database server that makes up aity Advanced care but if we follow the lines down this is where the question came to to John and to Mark was the fact that hey I found this thing in my PDI called APM digital interfaces and Integrations and how can I take advantage of it and please keep me from doing the wrong thing and that's how we got to today but in what I'm trying to show here is that in initial conversations with the it application owner uh MCG was s seen as part of the Acuity app and not necess necessarily a thing that needs to be tracked on its own it was just seen as another application service so what we've been able to do is classify this as a business app with these being part of the service that runs on this and that it's a SAS app and that's where that API call is being made so this these particular interface servers are making an API call out to this subscription service out on the cloud that data is then being retrieved and it's being put back in here and is being consumed by Acuity Advanced Care and in that app there's a button that they push on and the purpose behind this app is for when you when you a doctor asks for a treatment to be uh paid for through the insurance plans the on-prem doctors here at at Banner or in other institutions have a place to go to say that the standard of care is to do the following it matches up to what the doctor's requesting and they approve it and then we also have an instance here where we're trying to we we're we run Cerner and we're trying to we exchange data between Acuity and Cerner patient information and we want to be able to register this and show that relationship that this app shares data with Cerner this app is dependent upon a SAS app to return things for its for it to be able to provide its uh capabilities back to the end users and that's kind of what drove this whole conversation with John how how do I how do I go beyond this simple diagram and take advantage of some of the more important things inside of that and here I'll show you an example this is what I'm talking about this is my PDI and in my PDI you'll see that under APM and we do own APM is we have this digital interfaces and this Integrations and there's a few YouTube videos but they're pretty sparse on uh that mean they show what you can do to put data in but it really doesn't talk about long-term use and how to map it back to the app and all that stuff so so my question is how do we use these features in the APM module and then in talking with uh John right is what is the future direction for managing apis and microservices so that we don't do anything today that we're going to regret because we all hate that so and Richard yeah can you go back real quick to your diagram with connect y there's a question here what's the difference between acity connect on this and um and acity advanced care so there actually two parts of the app so one is a one is a one is a one that uh they log into and which is the Acuity connect so uh the insurance uh folks that take your phone call uh that's where they go they log into this web front end and that's how they access the app this is more of a backend thing where they do the approvals so this is the this is the patient contact I guess you could call it and the Advanced Care is the actual approval and managing the author the prior authorizations in that system thanks that was Billy's question I hope we got it yep um I think that was the only question please yeah there's more we we'll bring you back on later if uh we go okay I'm going to stoping and and thanks John I I had asked that because I was just wondering if it might be better as separate applications um and then I would assume your backend is probably where you have your interface yeah so yeah we didn't do separate applications because they actually are have different cost structures they have different support structures right and all those kinds of things that doesn't apply here it's the same team supporting it it's all paid for through one entity um so we we didn't feel we needed to split it up so and they actually and explaining that to the it application owners less maintenance we were able to achieve the results that we want right from an application rationalization perspective and managing costs and all that we we felt that just the one was all was needed so okay we do have other examples of other apps where what you said is absolutely true right where we had to split them up um but in this case it's it's just how we rolled with this one but is it your acity Advanced Care that that's where your interface is one of them right so so that is just a that's kind of I guess you can call it more the backend application part of it right it's it's all one app it's just one part is the back end one Parts the front end I think that's the EAS explain it so so I'm sorry if I missed this the the um when your prod acut connect and acut Advance care doeses that install software or is that just the classification of the software that's on the SE systems so that is so from the vendor perspective right that's what they sell they'll sell you Acuity connect and they'll sell you air right right so right okay but since it's all by the same team has one it application owner One support group all that kind of stuff we just went with the one business app okay all right thank you and so this is being um this is just the CI is is that how you're representing it within the your database your your backend system yeah so the the business app and then the application services so these are all my application Services right and then services are running on this particular Hardware this is kind of more of a block diagram just for the purpose of us being able to input the data and get the data corrected because when we rolled this out it was just we hit people with a stick and said here please fill out all these fields right with not really anybody really understanding the value behind that or trying to get that and that's where I go back to what John was saying is that we took a different approach rather than just filling out stuff we started showing people hey by doing this you can imagine at 2:00 in the morning having even th this diagram available to you it it's worth its weight and gold and that's where we've gotten everybody's Buy in is that oh my God we've never had this before right and to have it available and we're tying this back as an architectural artifact through Lucid chart so so in your um your diagram so rows two and three are application services and they stacked as parent and child yeah they're kind of just this roow really doesn't exist right this this here doesn't really exist it's really this right so we enter this we come in through the through the uh through the U through the hardware right and it and Discovery finds this and we label it and we establish that relationship so is row four are those server CIS these are server CIS correct yes oop sorry okay okay right yeah yeah these are your server CIS this is the CI for the application service this is really just a logical representation so that we can keep the conversation with the it application owners uh aligned right and so really this really doesn't exist in service now it's just this Maps down to this so got it you mean Row three doesn't really exist uh yeah it doesn't because what this is is that this this runs on this right is the way to look at it so if I was to look at 7506 I would know that 756 is my Tomcat server that provides aity connect and it's the prod instance all right okay yeah kind of sounds like in a way you're trying to to map the the like the service mapping you're going going from the business app the app service to the application to the server yeah it's a poor man's way of um so before we were enabl to uh install service mapping we have to go through some rigers and part of those rigors we're doing about 10 of these applications this way and showing how this is all going to work and the impact uh Beyond this we're doing lots of things we're doing capability mapping we're doing information objects we're doing Aral artifacts right we're doing a variety of things all tied back to these 10 apps because we're following John's John's wisdom right show them the value well the value is in all of that being present not just having a pretty picture in in my in my business app table right and then when your microservice is currently with cstm and it's the examples are out there and now create um um a micros service is basically just another application service I think so yes you look into the sdlc component layer as sort of the design or build component layer to as a parent for those microservices and those being also a child of the parent business application yeah I I'll just say I haven't kicked that can yet so when you talk about microservices I'm not sure really where you're where where we're going with that right we're that's part of this conversation today is for me to learn more about that right yeah I'm just showing you where we're at in the process and how we've got to I need help with these API you know documenting these apis just like we're we're trying to document Sears right so tell me how to do it yeah that was something we looked in oh go ahead say this is Mary bana and I'm the one that created the microservices um data model example and now create and if you take a look at it even in his example here there's the we set up the microservice is the application service it may be an application service that's connected to and it may send data to or from other application services so there is a relation there I'll cover that in my yeah I'll cover that one and that's the Legacy way and and cover some of that Mary yeah cool all right whenever you're ready Mark I think uh that was your last slide yes sir yeah that's I just that was way more than I was expecting to be asked so thanks Richard appreciate it yeah no worries so I think everybody understands now where you're stuck a little bit so that's perfect for Mark to get us unstuck I appreciate that all right you gonna take over share Mark yeah yeah hold on Miss uh just one second my um my system locks up for some reason for a second and then it frees up so I think uh I think it's free again all right all right see if this works now is that working it's coming yep I see the whole deck right now all right well at least that worked um okay so so this is a kind of a product Direction deck um I've got a couple other product managers on the call I I don't I don't know if Nick can stay along here long enough to kind of get to his content I might skip around a little bit so we can address where we're going on on H A lot of the stuff we're going to be stating is forward looking statements so don't make any buying decisions on a lot of the the stuff that's not available yet that we will be talking about um so I've got a pretty um large I wouldn't say a large deck here but this is a problem that's been going on for a while in terms of how ubiquitous apis have become as a method of integrating everything right it's it goes back to what I would say is this man date from Jeff Bezos at at Amazon in 2002 everything needs an API and guess what everything has an API and and now everything integrates um it's a little bit out of control which is why I think that we're all here to a large degree we we're not sure now what apis are out there we're not sure exactly how they're used and that presents a problem um it's super important now because there are studies out there from companies like IB M who have characterized that most of your uh vulnerabilities are exploited apis in um in Cloud environments as an example so there this is sort just another one data point to use to substantiate the problem Set uh I think the vulnerability response uh Su Ops if you think about it that way all those are the the things that are driving a lot of what we're trying to do now um there there starting to appear in audit criteria if you're regulated okay so what apis are are you are out there are you securing them those are now questions Auditors are going to be asking and there's also some challenges in understanding the data lineage how information flows between the different systems in your environment um I'm I'm also getting a ton of questions on llms uh as folks are integrating things and llms and data sources are going into LL M that you're not really sure of so that's a whole another topic I don't want to get into today but uh it's another one that that's hitting hard so the the I want to start with this picture because of course it's cstm and there's kind of two halves of csdm the upper half where you plan and build stuff and then the lower half where you operationally manage U use and consumption and the these two areas are sort of the Ground Zero for a lot of the development that's going on in the product teams uh some of them you already you kind of highlighted digital interface digital integration I'll cover that to a large a high degree here uh that can be a whole session on its own uh but I wanted to set the context on where we're in we're investing on the bottom section which is what where I have some of my product manager colleagues on to answer questions about this uh picture because to be frank um as an architect in my past lives it's easy to draw a diagram and show how things are integrated on you know during design time it's very very difficult to understand how Integrations are implemented in the wild through the various technologies that provide that capability through middleware like Boomie or or moft or gateways like apy or Kong um or or just direct calls between app servers uh which happens a lot too Json calls or whatnot so um there's there's a lot of complexity down in this space that we're starting to tackle so um from that point of view there's the Legacy approach or current approach I would say where we do have um this depends on and sends data capabilities in the app Services where we capture the information about how the app Services rely on one another this is kind of what Mary was kind was was starting to bring up uh this is the the historically the level of detail that we were covering this problem for a long time and there's a lot of examples out there and I've got a couple of them following this slide that gets into some of that but uh this is sort of the the main thing that we have today and um it doesn't really have the clarity for the operational details however would you say sends data to from that sort of thing you don't know what data that is and and it lacks Clarity going through the middleware layers to to see what's really happening if there is Le middlewares like gateways uh and that sort of thing um and I've generally seen Cloud applications making this problem much harder to understand because your teams are now given an account on the cloud environment and those Integrations are now managed by by the by the team and and so what that picture looks like is becoming harder and harder to put back together for operational purposes so uh so this is just kind of the the the problem set if you will kind of substantiating some of the last discussion points I'm trying to hurry to get to some of Nick's content in time and any questions so far any [Music] validation there's a lot of chat stuff but John I don't know if there's anything in there that I should be addressing at this point no I think you're okay right now Mark okay um I don't want to get into the example models we do have a number of example models that cover this to a large degree uh as Barry kind of highlighted they're on now create you can download them there there's videos where we record this walkth through um but they are again they use that Legacy approach this the current approach of just send data or dependency model not a lot of visibility on what's going on with that interface at all I'm going to skip that for now so what what are the new approaches I'm gonna first cover for Nick's for Nick's benefit uh sort of what we're doing on the operational side I'll come back to the digital interface and digital integration second okay because what where we're going and and what we've already deployed is a class update called API which extends the Ste to BCI class and um there's a a a larger model growing around that in order to handle a more complex data model that is operationally accurate and and the reason that needs to be operationally accurate is because we need to support apis as they're implemented with real technology in in real data centers okay or in in you cloud or on premise so that operational picture needs to be accurate uh so I want to pause here and allow Nick to kind of take over some of the conversation if you're still there Nick I know you have to go uh are you on yep um yeah I'm here yeah so so uh I could go to the next page if you're ready or or or we can you have anything else to say about the data model that we just released no I mean this data model's been out for about six months and and there's probably um logically there would be questions of like what's the between like an API and an API component and things like that um the doc site does have a fair amount of documentation about it and there's also a community article with some examples of these things um but at the highest level the you could think of it like the API components are the individual endpoints like explicit URLs or resources that are all part of one API so that's the the biggest difference they can live independently but ideally our guidance is to have that uh that relationship built out between the API and its and its components yeah now I I'll also say a couple things one is there's a lot of activity on the blog there's a lot of folks that have chimed in added their to cents I would definitely encourage folks to to look at that blog and um it's pretty easy to find and I can provide a link as a followup uh the second thing I wanted to me mention is a lot of this model is driven based on operationally ingesting information about the current operational footprint of a API and integration is is that a COR correct statement there reck uh yeah yeah yeah so with that I want to give you guys a a little bit of a floor to discuss a a new initiative we're calling API insights uh that's the the the market approved name for this and it will focus on that operational picture so if you think about iton visibility as it stands today the visibility portions don't really cover these API details and some of the sources like gateways that are currently in use um so so Nick or Robie if you're still if you're on there um yeah you you can give a a better summary of this than I can Mark I got one quick question for you are API components not just some installed software so when there is a CI like a web application why would you need an API component a apis are a distinct element of the design of that software for example our platform provides a dozen apis okay and it's all one software component really if you think about it right um and so it is a separate entity that is needs to be understood independent of of the piece of software that's been deployed that's the only question for now on there thanks yeah he Mark uh Chase Bry here I I do have a question um what what's the relationship back to business app or application service that ties the apis back into the business so that tie-in is is not addressed yet in our current approach um I do have a white paper I don't know if I have sent that to you I'm going to talk about that in a minute to discuss how it could be done how it might be done it but it is sort of a feature um but today we're sort of building this out from the two ends of the spectrum the design end which APM covers uh I have a few slides about that in a minute and then this operational picture which is more of a discovery visibility point of view uh actual implementation of apis and Integrations so they will come together at the end of the day is the is the the future goal okay thank you so there's a lot of U investment if you're um familiar with service craft connectors uh Discovery Val we we are looking at a scope of gateways and data sources that will provide the information about what we're going to cover in API insights the idea is this gives you operational visibility uh based on these um these implementations and actual use of of apis uh this will be a dedicated workspace and that workspace will cover this this operational picture uh of those apis uh this from a monetization from a cost perspective uh we're still sorting out the details of that uh but you have this will align more or less with iton visibility and subscription unit pricing the ability because we're seeing a large number of these apis that would exist that need to be managed alongside the software which is a uh a simpler component but like I said before the the software itself does not tell you how it's integrated or how gateways or mule soft or mq series are are implementing those those apis or integration points from a timing perspective uh this has actually got a very short fuse in terms of our initial release of this particular uh product in The Innovation lab so Q2 uh we do plan on covering some aspect of this at knowled we don't know if we'll have a main theater type of thing but we we will be able to talk about it uh at knowledge to a large to to a degree and we have a control go to market in Q3 planned I think I might have lost Nick I don't know Nick are you still out there anything else to add on this page I think we might have lost them yeah all right um so this is just a high level overview of what we're working on from an A from an insights point of view and the form it's going to take in terms of a a workspace to to cover the operational detail what we haven't done yet kind of to your question there Chase is to bridge the gap between the the the design aspects um this this has worked well in terms of how we've done things to put pressure on the app Services layer if you will on the model uh many organizations might have a good app portfolio uh independent of Discovery uh what we're what we're trying to do is kind of bridge the two uh by developing capabilities from both ends and then come together in the middle that that's been an a fairly effective approach to this problem so looks like there's a lot of stuff in chat anything I need to address it looks like uh I'm getting a little behind I was looking for that is that that article on M on API is that in the csdm Forum uh no I will I'll I'll cover some details there since Nick has kind of dropped off I'll get back to that detail in a minute okay do you intend application service to indicate dependencies to API I.E my application calls your API or what dependency exist instead in the application service that implements and exposes your API it will be part of the application service because the app service is a is a logical construct these are actual implementations which is a more granular construct so my application service May Implement 100 apis I've done this before my myself and and those 100 apis and integration points might have um you know much greater detail that than what you would represent in in a single app service it might be a microservices architecture uh so you have to break it down into a lower level um so so yeah there will be great granularity in what we provide in this data model but Auto more automated too so the reason that we're looking at this more like the discovery process is that as anything changes with the configuration and use of the apis you know in these other tools that you that you may use already to implement them uh this model can be updated in a more automated fashion right so that's the idea awesome and will apis have a matching product model class uh we're not that far down the the row we just want to get the I would say footprint the operational footprint first the product models is something that I address in the white paper uh we could talk about that in a minute but yeah that that will uh I I think we'll come to that as well like I see these as Technical Services in the broader sense um and if you're familiar with the it for it standard talk about human and um machine consumption of what we call uh systems in the in the it for it vernacular I'm not going to cover that today but we we already kind of look at standard ways of C characterizing these um these in in some of the new standards like it for it uh there's a question from Jason you have a hand up I don't know if it's still active yeah it's the one I I asked in chat just now I didn't realize we had to do it in chat but basically we're in the process of trying to do apis now and so we're excited to see what we're what you're showing us here one question we have is is this going to tie into the csdm information object so you have the actual information Lego that the API is using between the different systems or is it going to be separate from that not directly and I could speak a little bit about what we're finding a lot of the systems that implement the Integrations like gateways don't provide that metadata or they are an open text field description of something which has no governance or control over so from an operational point of view this information is very very difficult to come by also if you're if if we're looking at let let's say Network traffic uh some of the the contents could be completely encrypted we don't know what that contents are is right or mq series uh payload might be so there's a it's not as easy to understand that um the type of information at an operational level but uh we it is it is part of the reason we want to tie this to the design okay so when we when we have the design context uh I and we'll cover that in a second we should be able to obtain that information okay so from a Discovery Point I I totally agree with you it's going to be very difficult but if we go in if we have a data model identified that we can then align our business apps to to say these business apps use these higher level information Concepts or these types of information like pii Etc that we can then tie back to some of these apis is it possible to do that yeah that that is one of the goals and I I cover it in the white paper that I referenced I I'll I'll I'll review that here in a second uh kind of what the the the division is if you will in the paper okay um so actually I'm I'm going to cover the what's next here after I go through some of the content that I was rushing through U I'm G I'm G rewind in this presentation a little bit so when you see the presentation it will be a little out of order uh from how we're going through it I wanted to to take us through the microservices example really quick uh the the way we do things today and we have we have two different specific examples that we we have out there okay there's a decomposed monolith which is a typical microservices scenario versus standalone um I'm not going to take a long time to go through these because this is published material that you can see today um the idea here is any microservices situation you structure a large monolith into smaller microservices that are each doing a different job um this is a very simplified example of of three different products used one maybe customer created the other two are commercial products that are stood up and they create microservices which are now interconnected in this layer of app services so you have a a high level app service that characterize the full deployment of of this case an online sales management solution and then you have three microservices underneath that are each doing something for this overarching um larger application and I've worked on applications with hundreds microservices so this can get quite large and each team can be Mak changing a microservice within this particular app uh on their own from a governance standpoint it's still governed as a single business application a lot of customers have struggled with do I do I govern it as one or do I break out each microservice into its own business app and in this case if these are entirely encapsulated by a single team for single purposes then I would recommend um from a from a management point of view they all become uh under one umbrella one business application and under one app service to indicate the uh dependency view uh this also ties down into the underlying infrastructure if this is cloud or on crem uh if you have virtualization layers container layers all of that would be articulated underneath one microservices potentially and so that each one can be have a different footprint so we do we do uh uh allow you to in this model characterize each microservice on its own independent stack um from a API integration point we understanding how these microservices are integrated with one another is is not recommended because the the nature of the of this and the Dynamics of this is very volatile and what do I mean by that if you try to gather all the apis between all these microservices owned by one team there could be a lot of noise in there and a lot of changes that you don't necessarily need to see uh if you can get down to a single thing that's failing and understand the context uh so uh this is an area where I don't see a lot of emphasis on needing to understand apis okay so I just want to point that out before I move on to the next example which which is uh a kind of a standalone API kind of context any any questions about this ly did you have a follow on I don't know if you want to off mute or did he hit it on that explanation can you hear me yes I can hear you now yeah so you might have just answered it so if I'm understanding things right your API model is more about managing documenting apis kind of like from uh similar to your business architecture where you're looking at capabilities Which business applications provide this capability so that you can limit overlap in business applications and make sure you're meeting all your needs it feels like a similar model the way you're looking at managing apis what I'm wondering I guess is if we're documenting apis do we want to document that my application is consuming that API and if I do want to document that and my creating a dependency from my application service to an API or an API component or just the application service that exposes that API or both does that make sense yeah yeah I I'll cover it in a few slides so if you just bear with me you'll yeah I just want to cover the current state this is kind of how things work today uh from a microservices architecture this doesn't change too much you're going to see a lot more detail inside the application service that describes all of the underlying Technologies and API you know C eyes that make it up um but generally it's it's not so important here you know if you focus if you if you're thinking about focusing what areas do you need to bring that information in having the apis at this level is not so important um maybe this one this next example will will fill in some of the this this is an example where we we do have an API exposed for others to consume and in this case I I'm just picking on tax calculation because you can imagine this is a widely necessary component within a larger organization and in this case we we expose that API as a technical service that other folks can can then consume you can manage and monitor that uh you have slas and and commitments associated with it and people are updating the the taxation uh model right the as tax law has change you got to update this thing everybody can be on the same page um and the the current approach to integrating that today is really this depends on relationship um you can look at you know the nature of this application service and guess on oh this is tax data that's flowing by by right or maybe sales amounts or order amounts things like that which are characterized but there's no information object uh model there and I'm I'm and up here we'll cover this in a second here with digital Integrations digital interface you may have a similar structure to describe business applications are designed so this this phone ordering system may be a completely different business application over here and have a different uh design level model dependency between these so uh we we'll show you that in a second but this again Legacy how things are done typically with most customers today uh but it's getting a little bit more complex but much more robust as a result so Richard Does this answer your answer for what you're trying to do now I think this um I'm not sure I'm looking at it operationally John right how do I go and create the CI for the API right how do I create the relationship and I think somebody was talking about I want that I want that that relationship back to the business app I have to show that right yeah I'm going to need some time to digest this and probably have some follow-up questions and as I'm sure everybody else on the call does too right it's just yeah uh yeah yeah I mean I don't have too much more time to get through the rest but there's a few more things I want to make sure I cover it's really this new approach and and this has been a problem I I I purchased a product called CET I don't know if anybody here remembers that but um it was a when SOA came on the scene and we had uh technology like widdles okay and and uh we we needed a way of understanding Integrations that were available and and managing those um apis and whistles you know soap calls that sort of thing um and and so I've been I've been around this problem a long time and I documented a uh a a white paper which has a kind of a long-term overarching Vision about this uh you know going back to my syet days and it really focused on three key Pro processes which is when you when you deploy an app or create an app from scratch you may provide apis and the first process is registering what apis does each app even provide right before you even integrate anything the second process really deals with putting those apis in a catalog that others can then consume and in and in the white paper I cover how to create a catalog that's actually pretty easy there's a missing component like product models I think somebody brought that up product models would be make it even easier right you can use um uh apis as a product type product model type and then do this so um this is this is something we we think about in the in the paper as well and the last thing is uh deploying and managing Integrations operationally which is what I covered while Nick was on and how we're going to be collecting this information um uh from an operational point of view the um if you think about how we do Discovery today a lot of folks in a robust scenario are saying we're going to be deploying an app service and you may create an app Service as a plater non operational when it's deployed you mark it operational and then you do discovery which is targeted on the IPS that were changed or whatever scope of of discovery that makes sense so um there's some best practices on how we can take this down to an API level as well using the same approach but um the data models on the right are just the value streams that I've documented in the paper I'll send this to you all if you're interested uh you can read through it I'm on draft 13 I've been doing this I've been working on this paper for about five years uh so it's not an old uh we didn't start from scratch right this has kind of been thought something we've been working on for some time so just a quick pause any questions yeah lots of let yes pleases and hearts on the uh you said you'd give them out yeah and just keep keep in mind this is a draft it's not public the reason is that some of these red items didn't exist when I first wrote it some of these items like digital Integrations and digital interfaces do exist and I want to cover that because I think there's a lot of uh question about design level and we now have that and and so I'm gonna you know I think we have some of the APM folks on the call there's digital interfaces and digital Integrations that can be documented these are humans have to do this or you need to be able to import this information from metadata that might be described from a thirdparty product as an example but um here you can you can describe the digital interfaces and Integrations today and and use this as part of your APM product uh implementation um this is just a screenshot down below of what those digital Integrations do and they basically connect you know the subscriber and provider um um information between those different business applications through those interfaces uh so so very high level just a quick again this is information that's already available this is giving you an idea of the data model for the digital Integrations and digital interfaces and so it does incorporate the information object picture um you know because this is relatively new on the market I don't see a lot of what I call mature customers these days yet uh but I I could tell you from experience uh a lot of customers are are going to town on this okay this is a a critical part of design and governance and um allows you to do this the one caveat it does require APM licenses this is the digital interface and digital integration is not an outof the-box part of the data model it is part of the APM subscription so you do need to be an APM customer to use these elements and um so that's that's one thing to mention and that's why it's not currently part of CSD it is uh it's not common it's not out of the box which are some of our ssdm principles so just want to take a really quick pause I know other folks from the APM team are on this call and there's probably customers doing this already uh any questions or comments anybody want to come off mute I know there's a lot of comments but I don't see any questions on there right now all right no I'm hoping yeah it hits the mark though for some of the challenges that we're talking about still yeah hi Mark it's h it's Dave Hill here so so yeah I would say that this does hit the market it answers an important question that we have today on how to connect some of the application Services we've created based on uh your uh uh previous models for deconstructed monoliths to a design object that we can then use for governance and things like that my question is How likely is it do you think based on where we are today that this will become an element of a future cstm uh version uh one of our principles is out of the box okay so whenever that decision is made that's above my pay grade not in my uh wheelhouse uh we we could add it to cstm but that is currently a a a value proposition for purchasing APM at this point yeah but I would say that Mark it's very important that if for those of us who own APM and have occurred that extraordinary expense that in order to get True Value I have to understand how to how to use that digital interfaces how to take advantage of the artifacts and how to consume information objects because we're paying for it but we're not doing a lot with it and you know what happens not good things so yeah I mean so that's good feedback we can maybe cover this in a in a deeper do session uh or a video I think there are some published things out there um but maybe we can we can have some sidebars on that for folks that do own that I'll yeah derone and and Gerard are the product managers on there and there's a big outbound team that's there I'm an outbound team of one actually two we just hired another person in our team but uh yeah know this there's there's a lot more folks on that team that can help out okay so good good takeaway from for me at least we can work with that team and get more detail on that yeah we had Don on last year so it might be time back around yeah Don I don't know if you're out there or Maro I think I saw you earlier yep so I just want to say we're going to have a workshop on this it is planned for next month on the digital interface digital integration and we'll kind of go backwards from where Mark has gone starting at digital interface integration in APM and then how that ties in or will tie in there's some upcoming uh features in APM I believe it's slated for May Safe Harbor on that um but that digital interface will tie into the API components that Mark was talking about and I'm sure probably play a part of that overall workspace that Mark was mentioning yeah the trick is the change down here can be pretty Dynamic so the proper processes this information is updated first and then there's a change made in in operationally we can then tie back to the original interface design spec right that's that's captured here uh so it's a process issue the reason I I wrote the paper is because you got to think of it from design down okay design build then operate and and if you have everything robustly defined along that path you can tie back to the design but today this is a rarity I don't see a lot of folks capturing this data right we're just talking about it it's there it's in the product you're not using it well there's some definitely need because now you have traceability to the information that's actually built in those inter Integrations and that's super important okay and Mark a question um yeah this is Alan prosa from from Kaiser so what it looks like I'm I'm seeing a an evolutionary road map in my head you got a couple of um app services and then if you want to um model okay they they communicate with each other there could be the the simple relationship between them either communicates with or sends data to um receives data from but and so that would be stepping up level one then level two is we really need to know you know as you've been saying what's the nature of that integration what's the N nature of the the data that's passed and then that's that's when you would model um the interface between them as a separate CI so a couple questions one is um would those would there be a pair of relationship so that the the two app services are still related directly and then there's another one this three-part where they're related through the API and then the second question is um there'd be a a range of complexity over all applications in the Enterprise and some may not want to go to the trouble of and may not see the value in modeling the API as a separate configuration item do you see a a heterogeneous environment where some some um pairs of app services are have an API model and others just connect directly and is that a problem so yeah here it lies yeah you're kind of highlighting one of the challenges we have because to achieve sort of the vision in the white paper it really means you have all of this stuff established in the level of detail that we're kind of walking through now right um and and any any bypassing of this right is is a uh a low less optimal approach I'll just put it to you that way right um and customers aren't aren't going to have everything all at once right at a at a high level of maturity documented so that you can realize this kind of mature benefit uh this this is a huge challenge for us because we have to support customers with many many permutations and uh there there's no just one size fits all yeah but I want to make sure my goal just you know when I talk to customers about this from a strategic point of view is to to paint the longer term vision is to get you uh eventually moving along and we could break this down into maybe phases like you said um that might be a good way to characterize you know Legacy and current versus where can you be next right that might be an easy way to break it uh and we can provide some material around that I think I think this presentation largely does that it was just thrown together last minute over the last week to be honest uh and response to an ask from John um but I mean we could do a lot more to to me this is the Boogeyman any digital interface that's out there that's unguarded unmanaged improperly um safeguarded right that's that's exposure going back to that IBM report okay um this this in my opinion G keeps me wake up but uh keeps me up at night not much does but this does okay Mark I would comment too right that that you know I I get following the model right there's a series of things to do but the problem we're having is the fact that every day or not every day at least once or twice a week There's Something New coming through the door and it's coming through the door with the minimum amount of stuff captured and to now I just added Tech debt essentially now I got to go back and instead of it being part of the design phase to capture all this information up front before I allow it into production now I have to try to go back later on if I if I follow that other methodology right and and I'm struggling with with that just just understood understood I I think if you're are robust from an OP from a design point of view and robust from a from a discovery point of view it it's really just process details to work out the connection of the two and I do have another slide that kind of covers that to a large degree here but I I don't know if I have time to to get into it um uh but yeah I mean there is there is there's a there's a process here that needs to occur and and then you know it's hooking into your cicd pipeline and uh capturing this information as you go through this process you know from Step One planning through deployment through uh updating the operational picture based on you know the gateways or technologies that are actually implemented so this is just a a really high level again something I put together just to illustrate the point but this is the sequence of events that uh if you're tied in along the way all this data model could exist and be used you know along the way uh so Mark I do like your expression just process details um that's sort of a that's sort of a knot drawn to a scale remark isn't it no I know I know it it's just implementation you know yeah but you know the hard thing is just getting the data model right I mean let alone the processes and in which need to be integrated to keep the data model accurate so so starting with the data model picture you can kind of walk back the processes that keep the data model accurate okay so that that's kind of the approach the reality that we've seen is that is that when your processes are are confused or are overly elaborate usually you can walk back Upstream um and that's a problem with the data model so that because because once you get the data models really settled and and everybody seeing them in the same way your your processes get simpler so yep yep and I just want to leave you with one picture I know we're a little bit over time um this is our our current service graft connector road map and inventory um we added a whole new section for this because API gateways are such a big deal and this is going to grow over time uh Nick is on that team B Bob uh ravie I mean there's a lot of folks that are working on this now and uh you'll see some of these hit the market pretty uh pretty quickly so glad you got that in there were some questions on API gateways earlier so hopefully that addresses some of yeah yeah and we do have an ideation portal if you have ideas or or anything you can reach out to Nick uh or RI who are were working on that um so if interested reach out to Nick or Robie their emails are here they're uh and I think I got I I forgot a period there in Nick's email but um nick. Ryan perfect mark this is awesome we really uh got all our heads spinning I'm sure we got a lot to talk about on the Forum well the good news is we we've been thinking about it too okay and and we have a plan um is it perfect I don't know but we have a plan we're going after this and we um hopefully we're going to solve your problems that's the idea otherwise we wouldn't be here um and We're In It Together awesome thanks again really appreciate this and we'll definitely be tapping into some UPS this year so thanks Mark my pleasure and great to see so many familiar faces uh out there uh thank you very much for your time