[Music] hi this is mark bodman this is our example series of the cstm youtube videos here we're going to cover four different platform examples we're going to cover servicenow as a platform sharepoint is a platform healthcare platform called epic which is very common in healthcare industry and sap which is another common platform that we typically see in large organizations for these examples we're going to look at how the different cstm elements are used within the examples and how they actually fit together and we're going to follow the whole crawl walk run fly methodology those are things you can learn about in our foundations training and our lab if you take the lab on our now learning site but for this platform examples what we're going to do is we're going to run through this at a high level from a business application point of view and the first thing i wanted to really discuss is that we have two different types of applications described here there's an architecture type attribute for the business application which describes the kind of business application it is and in the case of a platform host or platform application there is a specific relationship that we capture here which is a dependency between the two so here we see that the business application called servicenow change is created and it has a specific dependency on a platform host called servicenow so these are applications in this case that are created specific for the platform service now and the platform host is a particular type of application that will have number of business applications on them and that that's really what we're seeing is most large organizations have a strategy to establish a platform architecture versus having a lot of independent applications so having this particular architecture type allows you to better understand how you're migrating individual applications over onto platform applications to be able to support a platform strategy as we flesh this out and we go down to the next level of the architecture we see application services and what you see here is a very similar structure when you see the business application called hr servicenow hr on the servicenow platform a similar architecture is represented in the example here you see that there is an application service which is the servicenow paris production environment and on top of that would be the servicenow paris hr production application service as well so what we see here is a parallel structure between the applications that are on the platform and the platform themselves here we don't have environment information but when we actually look at the application services we see that there's a application service for the and host itself and then each app on the host and there's a depends on relationship between them what this really tells us is that if the host goes down all of the particular application services on that host are also impacted so this is what we need to be able to capture the fact that these are two different application services and one is dependent on the other in order to run we also see here examples where we have sub prod environments of the platform qa and development environments and then we also see here the application software depicted which is the servicenow platform software there's a separate instance of a application service in this case for the mid server which is not part of the platform but it is necessary for certain products on the platform to work and this is the servicenow mid server which has been deployed on infrastructure in the customer's data center so obviously the mid server is not on the platform itself but it does support the platform and it provides functionality that specific products on the platform require in this particular situation the application service for the mid server is running in the data center of the customer and there is visibility of the underlying hardware the platform of servicenow from a customer point of view they don't necessarily understand the hardware underneath but there is a url entry point that is different for the application service for the platform versus the apps on the platform and likewise we have different owners and different purposes for the platform versus the particular applications on the platform the platform provides services to be able to host these particular applications and is usually a different owner and it goes through a different governance process than the applications that sit on the platform as we continue to flesh this out we all indicate here we have product models that are associated to the applications that are sitting on the hardware in this case we don't have any hardware but we have a platform application that is associated to the product models and the product models would be able to capture things like the g8 end of life and then a support date which is typically published by the various vendors in the market including us also part of this example is we're showing a technology service both at the hosting level which is just purely for the infrastructure so if our customers happen to deploy infrastructure from one set of technology services this would happen at this layer and then the technology service for managing the platform that is at this other layer at the top so that would include things like being able to manage the mid servers as well as the platform itself which is hosted in the cloud prod and non-prod environments what this allows you to do is to host and facilitate usage of our platform in a non-prod environment for people internally to test out new functionality that they build or that you might want to deploy at some point in the future and then of course when you're in the production environment the cascading support of the application service on the platform to the platform itself can be managed because now you've established a technology service for the platform and to be able to manage the platform to its expected sla and olas as we continue to flesh this out and we look at the actual consume domain we see that the particular hr production application service which is on the platform is providing a very specific business service in this case the hr product that we sell is there to offer two different styles of onboarding we've got an on boarding for the mobile environment and an onboarding for the enterprise and this is all part of the onboarding business service which is part of the new employee portfolio category and portfolio of human resource as we further build this out we can see that the business capability of human resources is the one that provides this application they're the ones that basically are the sponsors for creating and managing a business application that's used by others but they're the sponsor and i like to call this the funding vehicle so hr would fund that particular onboarding application and of course uh there's choices of what kind of uh platform that might live on or they can basically use a standalone application but all of the applications that are typically funded and invested in are captured but we also have this linkage here which indicates that the onboarding service is something that they provide to external customers so new employees if you're not an employee here yet you would actually use this particular onboarding service as you can become an employee but you also may have internal folks that use the same service in order to invoke or to do various tasks associated to the onboarding process so there is a linkage here for the business service back to the business capability as well as the service is one of the things that the hr department provides to the rest of the company the next example that we're going to go through is sharepoint in this case we're going to start out with this notion of having a sharepoint both as a capability that of a platform but then to be able to facilitate other capabilities in the organization such as very diverse capabilities in construction versus hr in this case we have the platform host as sharepoint business application and we're going to start out by looking at different product models and the product models you can have of course different versions of sharepoint in different environments and really depending on how you deploy sharepoint you may have multiples what we have here is we have the application service which is sharepointdev and that sharepoint dev is going to be hosted on technology services so as you need to deploy your sharepoint environment you need to understand what infrastructure it's going to go on and what that application is going to look like and that's where we tie in the application as it runs on the infrastructure and then that application is what refers to the product models in the foundation domain so here this is a fictitious versioning i just wanted to illustrate that you have different versions here all in this one particular model and you can support all three of them simultaneously and so this one is in development so you've got an application service which is the deployment of sharepoint for developers to use likewise you may have a very different version deployed for qa for your testing environment and then you can have an entirely different version deployed in your production environment of course this may be scaled out this may have load balancer so the configuration of these application services may be very different to accommodate scaling and high availability but in all cases the structure is pretty much the same you would just have additional devices and additional instances of infrastructure and applications in a highly scalable environment we also want to capture to make sure that there is a technology service for using the platform so when it comes to sharepoint it is a platform and it doesn't really do anything until you create sites on showerpoint and i wanted to point this out because this is really a technology service that you offer the rest of the organization it's collaboration it does require admin some administration capabilities by the folks that own or administer sharepoint environments so i would recommend making this part of your catalog so that you can train people and govern folks that create new sites and that's not done out of control without any kind of governance or oversight so by hooking this particular service into a offering and a technology service called collab services this allows you to better manage and understand the usage and also get the feedback on the platform itself as we continue to flesh this out as those technology services are ordered and folks order sites and they want to create uh distinct sites on the platform we have two different scenarios here we've got a construction team collaboration site which is very different than in this case an hr collaboration site which is for staffing plan coordination in both situations we have those established as business applications the reason for that is there's systemic governance for example for staff planning this is highly sensitive information and it may be very influenced or representing strategy in the company that can't be overly communicated without the right authority and approval and in this case we have an application service that represents each of the deployments of those particular business apps one for the collaboration of the construction team another one for the staffing plan coordination that the hr organization is managing so what you see here is the dependencies between platform app and platform host is also recognized in the application service dependencies as well again this is a situation where if the host goes down for sharepoint all of the application services on that particular host goes down as well and in this case you also have line of sight to the infrastructure so if a specific piece of infrastructure that's part of that host is impacted by an outage then everything on top of it through this particular traceability from an incident and change management you can actually trace and manage the last part of this is really looking at the consume domain and knowing that you have hr services that may offer the staffing plan business service and then you have the offering of staffing collaboration so for example if you have a management team that needs to be able to coordinate and manage staffing plans with our hr organization this might be the way to do it and this might be open to managers but not individual contributors that's just an example but this is just how you'd want to set up that service so that folks as managers can come in and access those particular application services and do the work with hr so this next example is the healthcare platform example and here we have the same pattern we're going to have a platform map and platform house scenario so as i build this out i'm going to show you that we have in this case the platform host which is epic and the epic is a common platform folks usually know epic by name and would refer to their application as epic in this case we have the emr business application here we see multiple instances of epic we have a production instance here and we have different application services for the modules on the platform in this case we have an in clinic doc and a my chart module that was it's installed on those particular platform instance and there's a dependency relationship established between the two again if the epic platform is installed on premise or in the cloud there may be a reference to the underlying application and the underlying infrastructure that makes up epic here we also show the technology services for the underlying hosting of the infrastructure and then of the epic platform management now a lot of times again you have a scenario where the particular epic platform administrators may know how to administer epic as a platform but may not understand the business application so a lot of times the the modules or the applications on the platform would be a owned and managed by a different team in this case we also show you that the epic application service in this case we have two different modules or application services represented that depend on the platform but offering two different types of services one an inpatient service and the other one is outpatient service offering on top of that we have the registration so when you go to look at the service itself that's the registration for implant patient versus outpatient and then in this case it's part of the imaging portfolio you may have the same service used in multiple portfolios or the same application service used in different offerings so this could become a little bit more complex in terms of how people access this but it can be highly tailored to the specific locations so for example if there is a hospital that does not offer mri then this service may not apply to a specific location which doesn't have those kinds of services so the location information is also important as you start looking at the service design and how those services are consumed by individuals as we continue to flesh this out we can see that epic we can have different versions of the epic platform as version 2. 21 here and version 30 here again these are fictitious model numbers but here we're starting to introduce a level of information about the products being used and the versions of those products that come from your vendors or internal teams at the very top we see that we have a one business capability of patient management and another business capability of medication management and that is where the two different sets of business applications come into play one set for my chart and clinic for in and out patients and a very different one here that's shown for pharmacy management which again may only apply to certain locations and may be deployed differently on different infrastructure if need be epic does present a higher level of complexity just because of the nature of the location and the hospitals and the the way that organizations would package up and segment certain deployments that require certain modules for functionalities that are specific to a hospital or a location so these are things that are all typically dealt with and more complex platform scenarios like healthcare in the epic platform so in this last platform example we're going to discuss sap so here we're showing how sap is it's a very similar pattern where we have the platform application of sap and we have different applications that reside on the sap platform the the top ones are the platform applications the bottom one is the host in this case here we also show you that there's a host service application service for the actual host instance and this was is in the production environment and then we have a module out here installed on scp for manufacturing and that is the production version of the application service that deals with manufacturing functionality on sap now here we can see there's a dependence on relationship so anything that goes wrong with that particular instance of the host all of the applications that are on that particular host instance may go down as well as we flesh this out we also have show you that we have different tiers of technology services we have the hosting service for the infrastructure the platform services for the particular applications support and then we have the technology services for hosting services of the sap platform itself so of course we may have different levels of service for non-prod versus production environments and we may have different offerings for different instances based on the deployment and the footprint so we may have a north american deployment of your sap environment that is one instance of one application service and then you might have a south american application service which is on separate infrastructure deployed in a south american data center so you can extend on these depending on the particular footprint in the pattern but you still want to relate those back to your technology services which are managing those particular deployments even if they are in different data centers as we continue to flesh this out we can see that this in this case the application service that is on the platform is offering manufacturing and that may have multiple functionalities in this case we're showing an offering that has inventory management versus production line statuses both are very different but they all come back to using the same exact functionality on the platform we're also showing that we have a manufacturing management business service which is part of the manufacturing portfolio and part of the business portfolio as we continue to up the the stack here we're looking at the capabilities we have the ft sap hosting management capabilities which might lie in i.t itself it's seen as more of a technical capability providing technical services as we outline here on the left but then we have logistics business capability which is purely run out of the business and they of course have applications running on the sap platform which are to providing logistics capabilities those particular business capabilities would also tie back into the service so you can measure how the feedback and the health of the application based on the service and the service delivery that is expected from an sla ola and commitments point of view that is established at the offering thank you very much for listening to our example series this one on platforms please comment below on any kind of additional videos you'd like to see or if you have any feedback on these examples we're always trying to improve so your feedback and comments are welcome thank you