good morning good afternoon good evening everyone thank you for joining the second session of our digital product release launch and learn today we're going to be talking about how DPR can help modernize change and I'm your host gregis if you haven't joined the session so far um before we get going we have our Safe Harbor you've all seen this many times now um but there may be some forward-looking statements in this presentation their best based on their best understanding at this point in time so don't think anything as set in stone as it could change okay Greg uh I'm sharing my screen can you see it yep perfect okay uh so again thanks everyone um for today I've got uh just two slides to set context for DPR in general since there are you know new people that will join in these sessions um and this this kind of goes back to the poll that we just asked so uh today as a part of digital product release we are focused on being the kind of process orchestrator uh for the the Readiness of software products uh the reason why we had that poll question is while I have owned like my name's been on release management release V2 for I think the past seven years but it's been something that my name's been attached to but I've been working on like our Enterprise agile planning capabilities through agile. and safe I've worked on Dev Ops change um is so when we started working on DPR most of my interactions with customers were about that how do we make sure that what we want to deploy is ready and so we focused on making sure that what we wanted to deploy was ready however since we now have DPR out we've been getting questions from customers about okay well what about if I've already got something certified and I want to manage the deployment which we were ring on change management for that but from the survey questions and also from comments from customers rolling out DPR that looks like an area that we need to build so this is helping to influence our road map same thing with infrastructure I have gotten I think two requests over the past year for Hardware infrastructure releases however from the poll questions it seems like that's another area that we need to build to be able to manage you know hardware and infrastructure releases uh so don't be surprised if you see emails from me asking for more about the areas that we haven't focused on because we really focused on being how do we make sure that a release is ready and then hand it off to change to manage actually deploying it uh which is a part of the goal for today is to talk about the change side that being said again don't don't be surprised if you see emails from me asking to learn more about your deployment process and learn more about your Hardware infrastructure and Patch releases um so that we can evolve DPR because while we're a new product I I have a road map um which includes many of these things that goes out for quite some time like we will be focusing on this uh and bringing new capabilities out um uh for a long time I've got multiple scrum teams working on this uh so thank you for that feedback but we've just to again to set context we've been focused on how that first option how we make sure that something new whether you've built it or whether it comes from a vendor how you make sure that that is ready to get deployed uh to you know your various environments um and we've also taken an approach where DPR does not require that you have everything ready on day one we start off with that kind of I just need to streamline and see what's my process um and you know I have some approval but we're really about getting visibility that's where most customers start and then we can start integrating other Concepts like with release planning being able to schedule what are the features the epics the stories um that we want to deliver so that would be the next step uh then being able to have more of uh a a expanded policies to look at lots of data within service now in order to leverage whether it's devops data leveraging our devops data model or whether it is leveraging other data and service now we can use that information to put more Automation in place uh eventually moving to having a completely automated process my goal is for uh release to be something that happens in the background that we have automations in place to validate that we've done everything required that we don't need to necessarily have approval tasks uh or change approvals that are looked over by people that if everything is going the way you want if all the data indicates that we have a good release and we have everything necessary to create that change and automate it then release becomes a completely automated process that's the goal uh Mo I I'm not sure that anybody is fully uh at that goal but that is dpr's vision is to help automate that process end to end so today we're going to focus on the lad half where we have a a release that is ready and we want to connect it with change management in order to help modernize change because a lot of feedback I've gotten from customers over the years is that we have put a lot of release processes into change management which makes it harder to authorize a change because there's so much more information that change needs to look at but changes toward the end of the process and so we don't want to wait until the end before we know whether or not we will be able to you know have that change approved so we'll talk about how we can use uh DPR um and and and again I need to set some context before I switch over into my ense so for those of you not using change models uh you are today using the standard using the word standard with change can have a little uh overloaded meaning but you use the regular uh types of iil changes where you have standard changes which are meant to be pre-authorized so these are things where you've done this change before you have a process they're very low risk so the authorization of the change is already done it's pre-authorized you might still have tasks and activities but you shouldn't really have um approvals in that uh process because it is it's pre-authorized it's kind of preapproved um then there are emergency changes these are ones where we may still have approval processes but they need to be very streamlined because something has gone wrong and we need to respond quickly uh and then you have normal changes normal changes uh are the ones that tend to take the longest amount of time however normal changes don't have to take a lot of time um and when I'm working with customers it's not uncommon where software that's being rolled out is using standard change uh however and and again this is this is all about your risk profile uh and how you like to handle things but generally speaking anytime you're rolling out new software for the first time uh so for instance since digital product release we have a new version coming out in August we're releasing quarterly but when we take the August release and we deploy it for the first time that really is a normal change we've never deployed 1.2 before and so because we've never done it it's a normal change that is the point of normal change it's not a standard change a lot of times customers will use standard change because of how burdensome normal change can be but as a part of what we're going to go over today normal change doesn't have to be a huge process because we can use data in order to streamline it and that's what I'm really going to go over for today is how we can use data to streamline the normal change process or the emergency uh change process um because again data can be used to help augment the decision-making process of people and then we have our change models these are going to be used when we get into how we start streamlining the process because while iil has the three kind of regular uh change types we're finding that we need different processes for different kinds of change requests so for instance with devops change they introduced a devops change model uh I'm going to show you a kind of software release Change Model that I've put together it's not a part of the product yet because we're still getting feedback as to what that change model should look like for most customers I I would expect you to change it but how do we get to 80% of what customers are looking for with a a uh DPR type of release um but you might have patching you might have different ones for infrastructure you might have different ones for uh for you know new applications that allows you to Define your needs for different kinds of changes they can still map to iil changes so you can have a patch release that that really maps to standard you can have a uh a new application release that maps to a normal change from a a concept but this is where you start kind of streamlining your process deciding how should it work for the different kinds uh of of changes so those Concepts we're going to be using as we get into the demo so what we're going to be going through are three scenarios uh so through this you're going to see how you connect changes to release and how you raise them through DPR but the three models we're going to look at I'm going to start with I'm not using change models yet and I really don't have an automated change process but I need to relate changes to their release so in this manual kind of release change process we're going to show how through DPR you can raise a change request it will be a normal change request in this process I you can use standard like all of the change models are available but in this scenario we're just going to have a routine change process the benefits you get from this even though it's not streamlining the change process you're starting to get visibility on the change side as to what release is this a part of and then on the release side of things you can see all of the change requests that are part of this release so this goes into the visibility side of the maturity model where you haven't automated your process yet um but you are still wanting to get visibility into what's going on so with that I'm going to switch over to uh to my instance and I have a release that I've already done some work through I mean I quickly created um uh some data but I'm going to be focusing on change re requests now for context because I'm going to use this release for two of the three way scenarios we're going to go through uh this was a very kind of simple standard um release process and I had you'll see a little flag on this one that says that this phase is the user acceptance validation and is a part of the release Readiness it's by this phase that we should know whether or not this this new version that we're deploying is ready to go out to production it doesn't have to go to production at this point but this is when we know that it's certified that we have a good version ready to go out to hand off to change to take it through the deployment process and we are in the deployment phase right now uh which is where I'm going to be staying for this this entire time and we have uh change requests now I wanted to make sure this was going to work ahead of time so you'll notice I already have a change request called uh test uh but I'm going to make a new one so I've navigated just to start if I were to log in for the first time we come from home and we can navigate into our releases I would then have the list of my releases and I'm going to look at this eShop portal summer release which takes us back to where we are and then we have have a place here for what our change requests are and so this is showing me only the change requests for this particular release I'm logged in as Joe um Joe you've seen in our first two uh sessions he's one uh part of the outbound team uh so this instance is his and I'm just logged in as Joe so right here you can see a new button so I click on new and I am presented with the um the changes for oh I wonder if I think I got logged out nope no I didn't just took a moment uh and I'm presented with the change models so even if you're not using change models uh you'll still see models that may exist and one of those models is uh a normal change so I'm going to say that I want to create a normal change and I click next and then I fill some things out so you'll see that we pre-populate what is the release now under the covers we're using software model so we're we are uh fully bought into the common Services data model and since you can use this outside of release management to represent what it is that you are changing uh not where so your your CI so if you have a configuration item uh and you I'm just going to pick one um so if this is where the configuration item is where I'm deploying it to what I am deploying is the software model so we've pre-filled in the software model for you um and then the configuration item or the service if you are picking a a uh a service I'll just I'll just pick a service um those are what you're changing but what about it is changing is this software model which is the version that you are going to be uh deploying so I'll choose that U maybe I'll pick an assignment group it's going to go to my application development team give it a description a new normal change and I'm going to save it so at that point I have now a new normal change uh but you can start to see from a visibility perspective you can see things like what release is this a part of I have some of the release details uh because we have a connection from the change requests to the version we're deploying to the release uh we can start getting visibility into what's going on for the release itself now at this point I don't have anything streamlining this process so I'm in the new state right now I can move to the assess State whatever your change process looks like today we're not modifying it at all so we can start to use change requests as they are today raised through DPR giving you visibility into the release information so that's the first mode where it requires no update to your change process but you're at least getting visibility into what's going on so before I move on to the next where we'll start automating things are there any question questions that are they're in Q&A um i' I've see at least one has popped up in some chats uh so definitely if there are questions this is a good time for us to pause for a moment and start start answering them yeah we have one here from Nick Nick do you want to come up mute and uh ask live I think you'll have to hit the button for Nick to to ask yeah there all can you hear me yep yeah cool yes so I'm just asking can a change the SK raising the change module be link back to the release or will it only show changes that were raised on that particular screen yeah so the key is this software model field being filled in so once digital product release is installed we add a field onto change for the software model right okay and so long as that field is populated then you get the same benefits so and and in fact the first customer of ours that went live um they create the change like they they create it from the change itself and reference the software model uh instead of creating it through DPR so so long as we have that field populated it works cool and then that page there say that would look so our change screen looks a lot different to that so I assume that it would it would look the same as our current change request screen yes so this is just the outof Box um and so if you have customized it then we don't uh we don't impact your form view if you're using S so uh then there's a little bit that you might have to do if you want to see like the release details uh in s so um because we're also not going to impact your s so implementation so the linkage is there and we can definitely add this but there might be a little bit of extra work just to add it into s so cool and I presume the software model box on the change request if it's left blank it's it's not a it's not going to cause an error or anything yeah cool yep does nothing that's correct great um I think that covered desire's question as well um saw a hand raise yeah I think I saw a hand raise come up so if uh if we also want to see is there a hand [Music] rais I just saw a notification but I didn't see who so if you do still have a question and you hand raise uh we'll bring you off you yeah okay Jay hey thanks thanks for uh taking my question uh Mr it sounds like we have to have a a a software model record um in order to truly take advantage of this is that fair to say so it is but we do it as a part of the the process of creating the release so if you have a release then there's a software model that exists okay so I'm thinking about you know the entire life cycle of the the product right so my product management team is going to have to know as they're as they you know looking at the road map and releases for the road mapping and the find eics and all that stuff um incorporating that creation of a software model is something we have to ensure takes place through that process right yeah so let's take for instance this esot portal that I'm on uh I try to hide where I can um like what tables you're interacting with because your product managers probably don't know what a software model is I mean I didn't and I couldn't have told you prior to me being at service now and working if if you all know Mark bodman he and I have been working together for years he's kind of the Chief Architect of the cstm um uh so like I've been explained the difference between like application models and software models but most people it's kind of like the Nuance when I came to service now I could not have told you the difference between a normal change and a standard change because you know those words are synonyms in English so yeah yeah yeah the same challenge right we're we're g we're have to explain these different concepts to our product Ms well hopefully what we have is we have versions and we can request a version so this is just in DPR this actually creates the software model behind the scenes which then they can through release planning see all of their versions to manage those uh so by using terminology they should be already familiar with the fact that I have products I can go into my product to manage it I have versions I can we have it as request because since it is a software model if you have a process around it then you can it's a catalog item so you can change out the catalog item or the process behind the catalog item so it by default it just autoc creates um but if you need an approval process for that version then that's why it's termed as request version instead of new uh so when you request it it asks them and then the version exists they don't have to know okay and that's why when we raise the change request we fill it in for you so you don't have to know that hey I've got this software model field we populate it to try and again keep the just general stream of things working without you having to know the architecture under the uh under the hood uh one thing we are thinking about and this will be more feedback uh is changing the label instead of saying software model which is what it is it's following the same patterns as like this is a service this is a service offering this is a configuration item should we call this product version uh instead of software model I was I was I that act product version would resonate probably better with our with our stakeholders and just without our audience um but and that's that's probably would work better for us yeah so the the now without us doing anything you can change the label but we're thinking about changing the label to product version just to streamline how people consume what it is because again software model if you're not a cmdb person probably isn't something you know the term for thank you that's perfect thanks okay Colin yeah we just have one on so does the change request look like your current UI change request or do you have to deploy s you do not have to deploy s so so this will then look like your change request if you are using S so then um then this will look different than S so because this isn't S so uh we do have um uh except I'm not I don't think I have S fully um uh configured but we have a way to basically pop you out into s so so that if you come from it from DPR but you want s so then it'll launch out into uh into s so got it but no s so is not required okay and then creating or updating the change or change task should that be an s or DPR uh it can technically be wherever uh s so is defined for more change so if you are a person that's really managing the change request s so is the better place for you uh but let's say you're someone on the product team and you just need to update a change task it's all the same data it's just the view is different so any updates here will reflect in s so anything in s so will reflect here uh because again same underlying data just where does it make more sense to access it great um do you want to more do you want to uh keep moving through just looking at time if it's if it's relevant um I can also streamline especially the last one for devops change so I'm I'm fine answering questions this is this is yall's time uh so I can go either way let's see so is software model equivalent to software model in uh software Asset Management it is uh benefit there is that if you are using software asset management and you have and you want to roll out a vendors new version that you've got then the the versions will already be there for you so you won't have to do anything to create those records They will be usable in both places and we have built some things custom to make sure that we don't impact uh your Sam implementation great and then through this view can you uh apply a change template um we can create changes and apply templates in our no so we don't have templates um uh so yeah that's that's where s so would come in um yeah so we just have a view into things if now if there were things defined in the change model then we would apply that because we're just using how change models work but any other templates yeah you'd have to be an S so for that great and then Patrick I see your hands up I know you have a couple questions so if you want to elaborate on any of those yeah just a follow-up question to my software model question in the in the chat um if you you know our application teams we don't necessarily that I know of have versions of releases for our homegrown applications we would would um um have like a release and we're releasing these features or capabilities during this release so to do this they would have to uh start using software model and versions yeah so we are uh so we're thinking about relaxing the restriction on when a version has to be created but the benefit is that uh and this is something I I'm going to go into with the second um uh actually discussion because I realized I didn't put this in but the next walkth through where we have a model one of the things that we are going to start having out a box right now it's just a recommendation is that when the change is completed you know close complete everything's good updating the model to the model ID field on the configuration item that way you will H start to have a kind of I I refer to it as a minimally healthy cmdb where your CIS will know what's running on them so if you have an app service and you deploy a new version we can update the model ID field on that app service to reference the software model that it is running uh there are additional Downstream benefits that you get if you're using like SE Ops because if there are vulnerabilities discovered we can start telling you where are all the places those vulnerabilities exist if you're using sbom same thing uh so we're going to start streamlining updating records there will be uh it'll be opt in but we're going to have the the things in place where once you say you want to do it uh we'll update the CIS with the model references to tell you better what's in your cmdb which then has traceability to stuff like okay well what were the features we worked on what were the test results if you have testing in place um if there were security scans we'll have that complete traceability by updating the model onto the CI itself thank you okay col I think we can keep going okay so for the next part so we started with manual change next we're going to go through what I call a semi-automated change where we are still raising the change request through DPR but now we have a custom change model and approval policy in place place to streamline change authorization so you still get visibility um you still see the status but change authorization which is typically where the most amount of time is spent on a change request we start to re um to reduce the effort by leveraging the release Readiness so let's see what that um uh I already went through that uh let me talk real quickly about the change approval policies so if you're not using them which about half said you weren't but at least most knew about them so I can talk about it very quickly change approval policies allow you to use information and service now to authorize or really to choose what the next step is in your change process is it auto approval is it send it to a person is it send it to a cab that can start to be dynamically chosen where based on criteria you can decide what comes next it's very similar to the policies that we have in DPR but where DPR policies are just are you compliant yes or no the change approval policies are meant for routing so they can route you to Auto approve route you to Auto reject route you to a manual approval based on criteria and we can connect uh this new model that I've created in order to start to streamline that process so I'm going to come back to my change requests I'm going to click new again again we're doing it through DPR but I have a change model for software release that you'll see I'm now using software model it is a normal change I am going to go ahead and choose the group and give it a name so this will be using uh using change model and save it so in this particular model allowed going from new to authorize um and what's going to happen in the background when I click save is that this change model is waiting for an approval but this approval has already gone through I I had an automated approval uh in place now the why I have an automated approval let me go on that real quickly so let's go to the approval policy so this change model is um again I kind of I simplified the Change Model A little bit because I allowed it to go directly to authorization and then I have a uh a kind of simple change policy because so I came from devops change while my my instance is loading and with devops change with devops change approvals that was looking at things like you know are all of our test results um completed uh are do we have any security vulnerabilities do we have any um any like code commits that aren't tied to stories those are all examples of the change policies that we shipped with devops change however um really all of that should be just a part of have like is my release Readiness phase that I'm looking at is it basically not non-compliant so there there are a couple of different options it has uh none means that we haven't run the phase yet so we don't know the status of policies um then we have as a compliant or is a compliant with exceptions because you can have an exception process let's say that one of your policies um you're not going to meet and so you went through an approval process so we're compliant but we're only compliant because there are exceptions so I basically I'm like so long as it's not non-compliant then we can Auto approve this now you can have additional things like I can look at the status of a change request but we're basically saying instead of um if I go into just my my uh policies like if I look at a a devops change policy then this is looking at uh far more not that one this is looking at more things picking the wrong one I looked at this in uh here we go so Auto approval this has a bunch of things that all could be and are in my case a part of my release process so I'm basically simplifying most of these out of code coverage integration tests load tests all of these are in DPR as a part of my release policies so if I look at my user acceptance validation I have compliant policies our user acceptance testing has passed all of our stories are complete in the packaging phase I have load testing and integration testing uh development phase I have smoke tests and you know all stories have completed uh commits so because all of these are compliant by the time we got to our for user acceptance validation I now can move through my change request so using this change model uh because all of the approvals are done I can move out of authorized and into scheduled now normally I would mark this is actually an auto transition I didn't just because I wanted to be able to have that conversation before it moved to scheduled but I'm now allowed to move past the authorized phase and into the schedule phase because my change approval said if my release so if if my eShop summer release is compliant then that's all I need in order to authorize it now you may have some other things like let's say you have a risk assessment you may still want the risk assessment to be a part of that um that change approval definition or if I want to know if there are any open incidents all of those things that are on the Run side still completely valid things to have in your change process like in your change approval but anything about the release itself you can simplify it to just is this release that I'm looking at is it ready am I compliant with all of the previous things that I have in place and if I am then I have now semi-automated and reduced the burden that goes into the uh change authorization I haven't changed my process I've streamlined change authorization by looking at release and all I really had to do is say is it I guess not non-compliant I could have said is it compliant or compliant with exceptions but I I picked the simple option so I want to pause here before I get into the fully automated change to see if there are questions around using my yeah the fact that I am I am compliant that all of my phases are compliant um to manage change authorization uh right right now nothing in the chat so if folks have questions please just raise your hand and we'll talk through it live all right well we have 10 minutes so I will go to and if questions come up while I'm talking about the devops one uh then you know well I'll certainly answer those so now let's go into the the last way which is a fully automated pipeline change so the difference here is you'll notice my first line change your quest is raised through your cicd pipeline so this would be Jenkins uh my example I've got GitHub actions um it could be Azure devops whatever you're using for your pipe line that can be used to raise the change request itself so we're no longer manually raising the change change happens through generally a release um cicd pipeline now the benefits there you still get visibility uh you still can see the status of the release on your change request it reduces even further the authorization overhead because you're using release Readiness and devops data so you have um you know even more data access uh but the two additional things that you get is on the change request itself you will also have access to all of your devops data so that would be stories artifacts that you're deploying um test results security scans that all becomes available on the change request and it also has the lowest effort on the change creation managing the whole authorization process because you have effectively fully automated it through devops change and connecting it to the release itself so devops change um allows you to automate that process so we have a doops change model I'm not going to go through all of these and leveraging all the Integrations and data to automate that process and really it's looking at all of your data including it in the change change process if you need and you can manage the performance like you can see the performance of uh like flow metrics and other uh other items as well so just due to time I'm not going to kick off I'm going to talk through how it works uh and for that I need to change releases because my uh fmr early release is what uh what will have this data already okay so you'll see by navigating into this other release I have a whole bunch of changes and you'll see most most of them say automated software deployment that's because in this example I have uh GitHub I'm not going to spend a lot of time in and I just need to point to something where we have a GitHub uh release Pipeline and as a part of the release pipeline there is a step that says we are going to you raise a service now change so this step in the process is creating a change from your pipeline uh you can Define what goes on the change request so all of the attributes like what's it called um and you can include uh variables like GitHub has the actual like version information you can have the description in place your implementation plan all of the fields that you need filled out can be created dynamically as a part of raising your change request and while devops change came about before DPR and DPR neither of us require each other we already work together by saying if we need to reference the software model then for this particular one we're going to connect it to our fmr summer patch release so by including this as a part of the change creation process from GitHub CH uh from um devops change then we are able to without any additional effort able to see any change request that is raised as a part of that pipeline you'll notice that this is the product that Joe tends to demo off of because we have a lot uh of change requests that were automatically created here um but I said you get additional value by leveraging devops change so if I navigate into the change request itself um you can see all of the things that were created you'll see we have the software model um so the the version 0.9 for uh fmr loan was was created but we have additional things that we have access to when you raise it so we not only automated change authorization through a policy but I can also see what were the summary of test results so if I need to see as a change manager uh then I can see this information through devops change if I need to understand what were the results of our software quality so I can navigate into this and see uh any of the uh uh details around it so once this uh page loads I can get to all the the scan information like uh there's apparently no code code uh duplication um it it's covering 216,000 lines of code um I can see all of this information by navigating through the change record those are the additional insights that we get by connecting the change through the pipeline so we get basically all the pipeline information um and a completely automated creation process a completely automated if you want authorization process and most companies also um will automate that if we're within the scheduled period Then it automatically goes to the Implement once we're in the Implement State the pipeline runs does its deployment if the deployment is successful it automatically can close complete the change request uh so we've moved from a manually creating manual you know authorization process to a you know our second stage was where we had a software uh release model that automated the authorization process by using release Readiness to now a fully pipeline automated change which again now gives us all of the benefits of normal change but without the overhead that it typically incurs when you require you know a lot of human oversight when we have all of the data necessary to decide whether or not this is a good change to deploy uh so we've only got a couple more minutes um I went through that one pretty quick I see there's at least one Q&A so Greg yeah if you want to yeah we have a CIA I think your hand was up if you wanna ask your question first um you might be mutated if you're talking is this better yep okay I wanted to find out the testing summaries is that strictly just from an automated devops change or can that also be leveraged outside of with just a plain Change Model so it uses the devops data model so it at least needs to be connected to the change uh to the change request there are ways to connect the data without uh raising it through a pipeline but the one key thing to note is that the Integrations today pull test results from the pipeline if you have test results from like quality Center or I guess it's Alm now um then we can still collect it but um when we tried to build an integration between HPM and service HP said no for probably obvious reasons uh so it is possible to pull in that data but we couldn't support a out of the box integration um to to have it there so you can pull in from outside of the pipeline but it requires a little bit of work to set up the integration between something like an Alm and uh service now okay so even the test Management in service now so we're evaluating what we do with with service Nows test management 2.0 um I've also owned that product and that team and I can actually see this it might come in eventually to release management uh I've got a lot of stuff on the backlog but that is now coming up so we may have manual testing in the future but I don't know when yet and I don't know the demand yet so um that's say that is a thing I am evaluating um now we could actually bring in though those test results like we could we could connect that data uh and as well it's just not out of box right now okay thank you