welcome to digital uh services transformation forum um i'm charles bartley uh enterprise architect with servicenow i'll be the first speaker and cassandra kittle will be the second speaker um i'll let her introduce her topic at the start of her part of the session um so a little bit about me i'm an enterprise architect with servicenow i've been with servicenow about eight months now prior to that i was a lead global architect at a financial services company and i had before that for about two years and then before that i spent 20 years at a major aerospace manufacturer as a solution architect and enterprise architect my focus has almost always been the it tooling space so on the servicenow's uh the history of starting in that space has been a natural fit for me so what i'm going to be talking to you about is designing for as a service the point of this is future agility now everything i'm going to say here is stuff i've lived and worked in my career it's also terribly subjective there's a lot of opinion there's a lot of circumstances in it um what i'm sharing here is how i approach uh service design and standing up uh the servicenow platform and apps on it your mileage may vary uh we welcome the discussion so i'm going to start with a general assertion here and that assertion is that many maybe even most servicenow implementations start in in agile fashion they're focusing on an mvp they want to get value produced as fast as possible they roll out the platform in some initial set of applications in that minimal viable product configuration and what you get is a tool that's used by specific users for that initial specific set of use cases your mvp user stories and usually there's some attempt at the non-functional requirements what agile scaled agile would call the enablers or completion criteria um if you're really good at all this you're going to start dealing with governance you're going to start setting up organizational change management training dealing with availability scalability all the rest of the leds trying to get some common development processes but you're usually treating these ladder parts as an afterthought because your main interest is get to value fast and deliver working value and that's an awesome goal to have uh what i'm going to propose here is this approach is kind of insufficient and that there's a better way that that designing as a service that will be almost as fast and deliver much more agility down the road which will pay for that short delay in time and resources your initial stand up so if you were to stand up a tool and i'm using that word pretty uh deliberately here because that's how how you're treating the now platform you're skimping on some of the early design and operational decisions that are going to limit you downhill um you're prioritizing those initial use cases you're prioritizing sort of work fast as a team get product rolling and in the process you're losing sight of some of those longer term issues that are really hard to change down the road i made up a quote here on the right we never thought that this requirement would change so we didn't think we'd have to worry about it yet the moment you say that as a designer i'm convinced that requirement is going to come to you and hit you on the back of the head and make you deal with that requirement that requirement could be something like um what i call the one two or many problem we assumed there would only be one production instance but now we've got requirements for two or we assumed english would be the only language because we only did work in the us but we just expanded into latin america we just expanded into europe china middle east wherever um we assumed there would be only one currency or one exchange rate or one capitalization rate and all of a sudden due to that expansion we've got many that we have to deal with these types of problems are predictable they might be off in the future when that expansion happens but they're ones where if you design assuming you're going to have many um of those elements or assuming that the regulation is going to change assuming that you're going to potentially need to be able to scale in a different way in the future you're going to leave doors open that you would otherwise close when you hard code those decisions particularly for your immediate use case you end up with those closed doors that future expansion is harder you hear people frequently replatforming you hear of people having longer um delays servicing like the company that you just did a merger or an acquisition of um that sort of thing's harder because you close those doors early so if there's going to be like one design principle out of this whole thing you take away it's think about things at the start of your initiative to leave as many doors open as you possibly can for down the line you don't have to build what's on the other side of the door you don't have to spend time constructing you need to build those assumptions into your system that leave the doors open so what i'm going to propose here is that when you think of all the elements of the nail platform the platform itself the apps on top of it not just as a tool but you think about deploying them as a service that that mindset is going to put you in the right place for dealing with the challenges that i just said so if you compare this to my previous diagram i've still got the tool i've still got the users or consumers there's still processes involved what i've added is a service fulfillment layer around the tool that interacts with the consumers when you start thinking that way and you start doing the things that a service requires you to do you're building in those open doors that are going to give you a competitive advantage down the line and i'm referencing here from the agile manifesto that you're all probably familiar with welcome changing requirements even late in development this what i'm talking about here is early construction or early design patterns that help you actively welcome those changing requirements because they're not that scary they don't require things like completely re-platforming or starting over because you locked in your assumptions too early so how does this solve for for the future um there's a couple things that when you start thinking about that service fulfillment layer it forces you to do you start focusing on the customer's need and their experience because they're the consumers they're the ones that you're creating that service offer for they're the ones you're writing the contracts with it's forcing you to think about from their perspective how your service is constructed as opposed to from the tools um team or the tools immediate users which are often your service providers needs so that shift in focus i'll talk later about a thing called externalizing controls you're putting the controls of the service in the consumer's hand is a really positive design influence it forces you to think about how you're going to protect your system from the volatile parts of that service by volatile i mean the parts that are going to change continually or the parts that maybe they're not changing all the time but if they were to change they cause you to start over from scratch again again kind of going towards that re-platforming part of that uh protecting yourself from that volatization is something that us architects like calling encapsulation you wrap them in a in a little wall make them independent services and you formalize the interactions between those volatile parts and the less volatile parts your goal there is the parts that are changing are all basically wrapped in those walls you can change those parts without causing change throughout the rest of the system the parts that are more stable you're not having to update all the time just because regulations change or mergers acquisitions etc the third thing that designing as a service makes you is you've got to instrument your service for observability so you can see what's going on this is where your metrics your kpis your log analytics the whole observability world the monitoring world they all come into play here um you need to be able to tell what's going on because you need to know when your service levels are being reached and to achieve any sort of service repeatability quality etc you're going to have to automate everything you can possibly do so i mentioned earlier standing up things as a service takes a little bit more time a little bit more effort than going after that straight mvp the two areas where that happens is you gotta spend more time thinking and designing again you gotta be conscious of those doors that you're trying to leave open and the second place is in build construction you're going to spend more time on those observability on those automations on automating your build process automating your service offerings because those are the things they're going to let your service be sustainable and scalable hey charles yeah somebody asked um i think lou asked is this the scene between a project to build a service for somebody and actually building a product is this the scene yeah i guess i don't understand the word seam there so instead of doing a project um we're saying build a product that more people than one can use is that yeah i think lou did i did i uh characterize your question properly yeah it's product centricity with regards to the focus shifting from people in projects or still siloed because they're all working on different things but they're not focusing on the product and product centricity i'm trying to understand as they're seen between that philosophy and approach and uh as a service yeah i think services are best understood in a modern context as part of the overall product management journey um so so we've been generally in it we've had this evolution from we started up standing up tools itil uh three and it4at2 started talking services and then uh versions three of both of those standards started talking products those build upon one another and so so like the tool doesn't go away because you started doing service management the service doesn't go away because you start doing product management um i think what i'm talking about here will become a little bit more clear here with the shopping mall analogy and then i'm going to start getting into how to apply this particularly with regards to the now platform so with the shopping mall analogy if you treat the now platform as a shopping mall it will set you up as the right uh mindset for designing the services um that that you're needing so in a shopping mall you've got a large building on a large puddle land with a lot of parking you've got a bunch of independent stores in that building and one of the really critical parts here is the mall itself is a business it's got its own business plan it's got its own profit loss statement it's got its set of customers which are not incidentally the people coming in and out of the mall the customers of the mall the ones that pay the bills for the mall are the stores that are there in the model in the mall each store's got their own plans the shopping mall in general doesn't tell the stores what they can buy and sell or or who their customers can be it might put some limitations where it says like for example we don't want um i live here in washington state so so we don't want pot dispensaries um even though they're legal in the state we don't want those as a part of them all that that can be a part of the mall's rules but but outside of that sort of prohibiting things that don't go along with the malls business plan it doesn't dictate okay nordstroms or whoever you're going to have a sale right now and you're going to sell these items that's nordstrom's business plan um so you've got a shared responsibility model you've got contracts you've got chargeback going on you've got all these attributes of a service which i'm going to get in into a little bit more and when you start thinking of the now platform as analogous to the shopping mall where the platform itself is the mall the apps or the various stores in the mall it's going to set you up with the right set of walls to do effective product management for both the platform and for the the individual apps one of the things you're going to want to avoid here in this situation is too many of the apps that are owned by the central platform team so this is tying in with the product management theme this is impacting how you're arranging your teams it's impacting how you're governing your teams it's impacting the agreements between the teams and what you want your platform team to be is that mall entity with the customers being the apps you want the apps and the services that are wrapped around them be serving your end business and when you combine those two when you put apps in the platform team and you too tightly couple those two entities what you end up up with is a conflict of interest where the mall entity the platform is overly favoring its own apps the apps that you're deploying as a part of that platform at the expense of the other apps that are independent and where you usually see this is servicenow was stood up in an i.t context it was stood up for itsm itom etc and the platform team the itsm and the itom team they're all really good buds they all sit next to each other they're all working together they're all part of that same central team and along comes hr and along comes supply chain along comes field services all the rest of the areas of the business and what i'm talking about here is how do you set up the platform team to be successful for supporting the whole business not just that initial set that they were targeting at the start did that kind of help yeah that makes a lot of sense thank you so i mentioned i get to what is a service here first of all it's one of the most overloaded words in architecture i kind of hate it because you can talk to any 10 people and get 20 different definitions of what a service is that are all slightly different and they will go unholy wars with one another in the architecture world to defend their point of view so i pulled the definition from the csdm draft ii which was the most current servicenow definition and even here i think they kind of avoid answering really what is a service and instead they describe what a service looks like and the three things they call out here are you've got interactions with consumers you've got offerings to those consumers and you've got a fulfillment system and i think these particularly the sub bullet here the contract and conditions part of the offering are the those critical things that set you up for designing for fast and uh effective future growth so the interaction with the consumers when you're thinking designing as a service you're formalizing those interactions you're acknowledging the ones that you've got you're acknowledging the potential ones that come down the line and you've got to turn those interactions into offerings and you've got to figure out how to measure them observe them automate them all those things i talked about on the last slide with the offerings you're figuring out what your predefined options are that you're going to allow your consumers to pick from you can start doing things like differentiated service levels i i know one of the problems at one of my employers was we always designed everything platinum because we always had platinum use cases that demanded all the extra polishing all the extra service well a lot of our internal consumers didn't want the platinum they didn't want the time that was associated with that they didn't want um the extra security controls that were associated with that they want something faster and easy so when you're designing as a service you're always looking at a place where you can say how can i do multiple service offerings let's offer some gold or platinum level for the people that need that but how can i cut those costs and that time down to give cheaper faster better options for others and how can i let each of those offers work independently like i don't want all of the controls of the high security offering to be impacting anybody's maybe i need different sets of infrastructure to support that in either case there you're you're thinking those things out early where all that's being spent is thought time and electrons before you're getting to the point where you've again closed doors to future expansion and your fulfillment system you've got people you've got process and workflow and you've got automation and going back to my original premise about how people start building uh tools and systems usually they usually skimp on understanding the workflow and process they usually skimp on the automation they focus on okay sorry they focus on here's the initial set of users i'm standing up incident management for the help desk and they're not thinking how can i repeat rolling out new capabilities over and over again faster and faster to support all of my consumers not just that initial focus set this is where you're focusing on automating the performance of your service so you can keep within your slas keep your quality keep your time and then constantly improve your service the case study for this and i'm not going to drain this slide but the classic case study for this is amazon aws and when you guys get the the pitch here the links in the pitch um you can follow this and you can just search for origin of this and it'll bring you right to this article um amazon started automating their infrastructure life cycle because they had to they had massive scale they were expanding fast in the early 2000s um they just plain needed to automate as they started automating they realized they needed api service catalog all the rest of this so their internal people could use what they were automating they realized it was a core competency in the company they realized they could turn a product again tied to product management from the earlier question and now it's a massive massive business and that started because they realized this step two they realized they needed to turn their automation into services not just keep automating database install or web server install for their own use there's a couple a couple of design principles um due to time i'm not going to completely drain this slide either um i already mentioned the first one encapsulate your volatility you need to understand those parts that are going to cause your design to blow up or that are changing all the time and you want to isolate those you want to protect the rest of the system from that volatility so that future changes are easier to make and again this is where you start getting that uh downstream effect of getting faster and faster the more you go is you keep protecting yourself from the volatility you're able to change the volatile parts you're minimizing the blast radius on future just good general design principle automate everything one of the things you're trying to go for here is what i call the snowball effect you start small you automate the little actions every time you automate a little action it lets you automate a bigger action the next time you come through the next time you do that you can start automating an even bigger action so start like in in my background we started with automating server builds then we started automating web server builds then we started automating database server builds and all of a sudden we could automate full application installs and now all of a sudden we could automate multiple application installs you want to look for things that give you that that snowball building effect where the more you automate the bigger things you can automate again all small all isolated all encapsulating the volatility you want to pay attention to these service design details before you're paying attention to the solution so i think this is where enterprise architects have a particular responsibility when they're defining when they're out there saying we've got this new demand for a new app in our environment they should be thinking of this as a service and as they're helping to fill out here's the description of that new app and here's the business case for it and here's we're going to get it through portfolio management we're going to get staff funded prioritized they should be describing that in terms of the service and those elements i talked about earlier the service offers that are going to be a part of that service it's going to need knowledge bases it's going to need organizational change management it's going to need service levels it's going to have metrics it's going to need itsm and itom support is a part of that and they should build these things into their planning proposals the negative of this is you just increase cost and time because it takes time to do these the positive is again you're setting yourself up for future faster more agile execution because you know all of these things are going to change don't spend too much time polishing any of these but you gotta be thinking about them from the very beginning the last one here is externalizing your controls fancy term i learned it from one of my main mentors it's meaning put all the levers and controls of your service that you possibly can in your customer's hands um and it's saying it's you best serve them when you realize you don't control what they do with your service why they're trying to use it any of that just like the mall doesn't control what sales nordstrom has or what products nordstrom's selling or any of that but those controls are in their hands so they can use it to solve their business needs and when you start thinking that way going back to you start protecting the important parts of your system that need to be protected you build those automated guardrails in for the things that you truly can't let your customers go because they'll blow up other customers that sort of thing um and you want to spell out those limits that your uh to to your externalized controls plainly in your slas and knowledge based articles so i already kind of broached this one talking about servicenow platform as a service your main customers on this are the other apps because they're the ones who pay you they're the ones who are like the stores in the mall that pay the shopping mall so when you start thinking about those interactions your primary interactions are going to be things like how do i support onboarding new developers and new development teams onto my platform um when do i need more instances when do i because i'm expanding to new geographies that maybe have different sets of regulations what happens if i bring new business units again the mergers acquisitions divestitures those are going to cause changes your service now as a platform team should have plans for those different types of interactions and they should have offerings that support those different interactions maybe the new instance offering isn't going to be used very often and maybe we don't build that in our mvp but you know immediately you're going to need to onboard dev teams to start working on whatever apps you're on boarding turn that into a service offering turn that into something repeatable build in the knowledge articles to help a new deaf team get up and going start thinking about your sdlc pipeline as a service offering you're saying like we're going to promote we've got a dev test prod environment here's how we promote code between those here's how you insert your update set into that pipeline here's when we upgrade the platform those all become repetitive routine things because you've designed an automated and documented and trained everybody on how to do those and then you've got the fulfillment system which is fairly self-obvious um the next one here service catalog is a system i put this one in to show that design for many instead of designing for one assume there's going to be multiple service catalogs needed assume that new business units or changing requirements are going to require that so how do you automate that make it offering for getting new catalogs make an offering for the people that are going to be building the service offerings themselves start thinking about them as customers or consumers of your service instead of maybe trying to do all the work for them how do you support multiple developers each touching their own service catalog items at the same time instead of necessarily one central dev team you're going to have things like coding standards you're going to have peer reviews you're going to have um again the knowledge base documents you're going to have training that you're going to need to develop this is going to take time for initial stand up again at the expense or at the benefit of massive agility down the line i wanted to leave you with some references being a good architect i'm reading all the time um these two are two that particularly influence things in this uh pitch the first one is ancient like this book was published in the early 2000s my current employ our boss at servicenow actually introduced it to me more than a decade ago when he was consulting at one of the companies i worked for it's called architecture patterns for it service management making shoes for the cobbler's children in the the basic premise of the book is we and i t know how to do service management we know how to do product management we force our customers to work with us that way but we don't do that for ourselves we leave our own kids without shoes because we're so focused on our end customers and that's what we do in that initial premise that i said when we just stand up our tools when we focus on that mvp without all of the illegals without all of the elements of a service we're literally making our children walk around without shoes here we're we're not doing the things that we know our best practice when it's our own work we need to stop that we need to be thinking better and then the second book juval loewy is a former research fellow at microsoft he's credited as one of the inventors of microservices and this is one of the best books i've ever seen for architecture and design for that whole thing i was talking about encapsulating volatility he's got a repeatable method in this book that works very well with the servicenow platform in my opinion i think it's a brilliant book i think everybody should be reading it reading it its main focus is how to build software fast repeatable sustainable by encapsulating volatility so i highly recommend both of these books were there any other questions there uh before we get to cassandra's part i think you've answered most of them in anybody um i think i got all the ones off chat if anybody else wants to chime in carl's um just going back real quick so you talked about the concept of the servicenow platform team owning the the mall right mm-hmm and i think it says i think we lost you oh you're breaking up mitch how about now that's that's better okay sorry so yeah so did you say earlier that the itsm team uh might own the um various site to some applications are we considered still sort of the customers of those applications so how i would treat it is the platform is one set of tool with its services yeah and the itsm apps are another tool with their services and there's a dependency between the itsf tools and services and the platform tools and services what i would avoid is combining those two into the same tools and services org again but like setting yourself up for a future expansion you know if it gets on the now platform eventually hr and everybody else yeah you're wanting to make sure that sure that both of those groups can go into separate but connected right because there's yeah and then uh related questions so what about how do you deal with um cross-platform functionality like notifications or things that expand beyond just one sort of type of application so i think you've got two options and for for notifications i think that one's comparatively easy i would say that's a part of the tool and service offerings of the platform team okay when you start getting to other ones like let's say virtual agent i'll i'll say is one of the ones i run into most frequently where it's a bigger more complex thing it's still got to be applied in the different apps but there's multiple apps that can be a consumer i would probably treat virtual agent as its own tool with its own service as its own product with its own product manager etc and again i'd say virtual agent is dependent on the platform team and then for example incident management is also dependent on virtual agent and service desk to some extent like interactions i follow your logic i appreciate that clarification now now the downside of that is you've got more project managers you've got more scrum teams you've got more independent entities that you've got to manage more head count you've got a staff but i think the overall agility benefits of that are going to overwhelm yeah i think it's it scales well for large organizations but for small organizations maybe 50 75 it um maybe this model has to be sort of streamlined um you know you might have multiple hats so all right i appreciate that i think uh cassandra i think i think you should be able to share okay right see yeah sorry trying to find the unmute button because thanks charles i i know we had a bunch of uh issues with that with uh teams so hopefully with zoom we're getting past that a little bit i've had a lot of problems at once um i'm just trying to see if i can share so everyone can see my screen right it should say csdm and service mapping that's right okay i am a itsm manager at el paso county um in colorado springs i've been in this particular position for about two to three months where previously i was a problem change and configuration management process owner which is a mouthful in that position i started the implementation of cmdb and csdm and then extended that into my itsm manager role in a previous life i was an implementation lead for a servicenow implementation and a business relationship manager where i have the viewpoint of focusing on delivering value or desired outcomes to the customer so a lot of the conversation that i have in this presentation my end goal is to deliver value to the customer the customer in my case may actually be my fellow it organization members instead of an end user but by helping my teammates they can deliver the value to the customer so that's my end goal when i start talking about my implementation of service mapping i'm starting in the common services data model at the application service level the service mapping activity itself is done through a standard ui basically i'm working none of this is done in a silo i'm working with product owners or an application specialist or someone who basically knows what the entry points are and knows what the architecture should look like for that particular digital product when we develop the map we're actually looking at how it's going to be tied to the business service offering and the business service or technical service in some cases i find that the service mapping is especially useful for the technical support group specifically to do root cause analysis um checking on other incidents that might be in play things like that so right now i'm showing you the agent workspace view on a incident the reason why i'm using agent workspace is because i originally thought that you couldn't get to the service mapping on the standard ui i have since figured out that you can it just takes a whole lot more of clicking and knowledge of how to actually get there so the value in agent workspace is you can view the details of an incident without going to another environment in this case once you select the business service the service offering and the configuration item and save the incident you'll have the affected ci's and impacted services cis populated and then these information icons become available when you click on that information icon for like the business service you can see the level one relationships and access the dependency map as well as see other service offerings under that business service one thing i'd like to note on this particular view is we are still in the development service definition phase as i meet with product owners to review the service mapping and the service design defining all the attributes of the service to include the groups the sla um this model id and and version shown here is a little tricky because it's not how you get to it the way i'm going to show you um but as i meet with them and we define all the attributes and we get into a production and environment more information will be available such as the ci health the groupings that i just talked about and the sla when you click on the dependency views it opens up a nice map that displays all the connected ci levels to your filter definition most of what i'm showing is out of the box with no changes however i have asked for a default filter to be applied on the dependency view to exclude any file directories tracked configuration files configuration files and disk drives the reason why i did that is because the addition of those cis creates a lot of noise and we just don't want that um bogging down the view of the different ci's the icons are yeah is there any uses for those things i'm wondering long term would you just exclude that from discovery if you're not using it from what i understand i should not exclude those i just don't know for sure because i'm pretty new and i'm still looking for a cmdb admin okay sounds good thanks you want to be careful with that [Laughter] so on the details view with the selected icon you can see associated ci's the incident the problems and the related services there's also these icons which are configurable the lego looking icon is where you can get a pop-up showing the related affected cis the list looking icon is a listing of the ci's associated with the parent ci the wrench is an indicator of associated problems and this exclamation with the triangle is the notification of associated incidents the service offering information is very similar to the business service there are some differences in the detail area mainly associated with assets for some reason but the dependency view is in the same location and you can see the level 1 relationships here this is an example of what the service offering dependency map may look like and i'm highlighting the different icons security requested that i do not show you any server names any ip addresses etc that's why it's heavily masked on the service um on the details tab where we have the ci as a service map when you click on the info tab it shows the service map information this can be an extremely powerful tool for the network services group for example the server administrators may stop on this particular view as they're looking at the connections from one server to another but through the more icon they network services person can go to the advanced map click on a connection and see the network path where they can drill down to an affected switch router etc are you doing any event mapping to those right now not yet okay that's the that's the goal though eventually yes it is so um we're probably at ino maturity model one-ish trying to get to two-ish which means we have a lot of service definition to get through and when i talk about that service definition i'm talking about establishing an overall sla program which i want in place before i even try to broach event management yeah that's a lot of questions we get all the time is what do i start with it's like just start there's a million starting points right right so i talked about the application service and the business offering and the business service and you're probably trying to figure out well how did you or probably wondering how did i make that connection and the way i do that is by creating a service along with its service offerings through the service builder application so this is an example where my business service is enterprise resource planning our service offerings are more on sub applications of that service than it is on um gold silver platinum where a government organization you get what you get we're not offering frills and and whatnot sorry so on the definition on the operations section there's an area where you can associate catalog items dependencies and that service mapping that you created for that service so if i had a and i think i do i just need to work with the product owner to find out what those catalog items are i could associate those catalog items here to make that bridge between the catalog and this particular service definition on the dependencies i might have technical service offerings that i want to associate so on another one i might have something called account provisioning and deprovisioning technical service that i would put here this particular portion is at the bottom of the screen so i'm trying to indicate that here there is a tie that brings you to the service portfolio and if you've set up business applications you can make a connection there that will actually show up in your service portfolio so a service portfolio through the digital portfolio management might look something like this where you have if you've made that establishment of a business application here along with your service offerings and your business service you could look at technical services in this portfolio it's really configurable and this all items allows you to select that you just want to see business services you just want to see service offerings or applications i don't remember but i think you can also say you just want to see technical services this needs attention column allows the product owner to see right away that there is a p1 incident that there is an upcoming change etc when they're looking at when they the product owner is looking at the business application they can see the number of incidents problems and changes on the run tab i do not have all the applications turned on in my dev environment such as the grc so if i were to do a live demo i would show a couple of errors on this so if i look at the business service a product owner is really concerned about the upcoming influx of information into the service as well as what is actually going on with the service so i can't work in a silo again when i'm working on the implementation of this i have to reach out to my pmo office to say hey can you make sure that you're including these elements so that i can see it in the digital portfolio management when i'm working with the opex group i'm reaching out to them to say hey what are your plans for improvement initiatives how can we make sure that we're totally visible on what's going on as far as improvement initiatives with the services on the business service i can also see changes that have happened how many changes there are what the backlog is that kind of thing so one of the i'm going to stop sharing that's really nice have you have you got any um quick question before you go on the next one have you got any feedback from the um the solution owners on hey i need more stuff or this is great but i need that are you getting any of that yet or yes i am so at the beginning i said i'm focusing on delivering value to the customer in my case for this particular effort um the um sorry i was reading a chat thing the only or my customers are the technical support groups the different support groups on how they will use the tool in order to do their root cause analysis or see the other events one of the concerns that has been raised by customer support or the service desk is i still need to see what's going on within the environment which caused me to [Music] push the use of agent workspace so that they could see the dependency views from the network services group they have a concern about how this all works with change management so i have a lot more testing to do has something to do with um i'll come back to you christine has to do with um there they have a tier three layer and how do we make sure that we're not associating 200 ci's with the change when it's not really associated with 200 cis from the product owner view there is a lot of interest in on the service offering you can have subscriptions how do we target communications to the subscribers for a service offering when there is an upcoming outage an upcoming um or an actual event incident event that kind of thing okay i wonder what yeah i guess it would be of an outage and not um not necessarily the the solution owner being able to mass email all the people that are subscribed to their own service right right they just um the thing is our subscribers if you will will not be coming to the portal to view outages we have to actually push it to them got it okay you got a bunch of questions coming in you want me to read them to you so you don't have to read them all okay um are the service desk agents selecting the ci or are they trained to select the service and then the offering when you're on the um the incident ticket uh and if so are these uh all cascading this is a point of contention right now so they have not been selecting a business service service offering or even the ci's consistently we're doing a mass ocm effort to roll out the business services as we have them defined and to train the different groups on how to use agent workspace basically using the add car method hopefully you know what that means [Laughter] to do guerrilla marketing for agent workspace digital portfolio management etc okay and then um you are using service mapping right yes we're just starting so um one of the things that we've gone into is the pattern so right now we're focused on on-premise applications we have not worked on the cloud services yet we're trying to make sure that we um get one thing right before we try to add on to that thing yeah yeah and and uh alan asks uh you're you're connecting applications to catalog items you're doing that in the builder too um applications i'm actually connecting them outside of the builders so the oh i'm sorry he says applications and catalog items into a service oh yes okay do you use service offerings for each of them i am forcing the product owners to define service offerings good for you and i appreciate what's behind that statement all right and there's uh oh we got two more minutes so i'll go down the service portal status page for communicating getting out the status um can't really do that okay just our customers are very distributed it's basically citizens so got it okay and i'll go quick because there's a bunch of them so we'll do a definition of ocm um organizational change management otherwise known big change management you got it uh okay ocm organizational change oh greg answered that already okay i'm trying to keep up with some of these uh do you have subscribers defined in all offerings uh that are tied to the catalog items we are trying to okay it's a lot of the offerings are going to just be everybody right uh actually no so um for example department of health services might have a different set of subscribers than um pikes peak workforce got it okay you notice in regards to that question i'm sorry did you notice that the uh if you didn't have a subscriber that that impacted your your uh your user portal uh that's are having where the catalog item disappears if there's no subscribers oh i think it's because we haven't fully implemented the subscribers yet okay yeah lou ran into that problem you're talking about okay you have to set the uh used for the other related lists because if you associate a catalog item with an offering it will disappear unless you explicitly then on the other related lists uh let all users uh see the uh catalog okay i'll have to keep that in mind so we're out i'll try to get back to everybody's uh questions on here um got a lot of accolades on the presentation so great job cassandra i'm glad you uh you jumped in i'll um i'll make sure i'm a little more explicit i know there were people two very different topics today charles was real deep on architecture and cassandra was really into the operations aspect so we had different people on for different things and i didn't do a good job of making sure the agenda was stage right because certain people so what i'll try to do is if we're going to have vastly different interest areas like an architect area versus a operations area i'll be sure to call those out in the future on the agenda so that you can if people want to come in for certain topics and and not others they can do that so i know we had some people that really look forward to the architecture who might have come in later and then uh so what i'll try to do is i'll try to stage that unless they're pretty close together i'll try to stage it out like that so that we can have people coming in for specific areas of interest and then i will get the topic out i know we're out of time so i'll get the topic out for next week in by this friday so thanks everybody thank you