Hi
we have a large application portfolio consisting of a master application and set of related deployment instances. We are thinking of modeling this as a master factsheet as parent and deployment instances as child instances.
Is this a good practice? or is it better to only model the application master as a the only factsheet for the application?
Are there any suggestions for this specifically in context of Pharma domain?
We have done what you proposed for applications (parent/child where children are the instances) where we have a need to differentiate between the different deployment instances. For example, if you wanted to document interfaces/data between an application with multiple deployment instances to other applications and/or between instances, then you want to have a fact sheet for each instance. We also created a tag to specify that the fact sheet is a deployment instance.
We always start off with the "application master" as the only fact sheet until there is a need/demand to specify the instances and the resources to support maintaining the extra fact sheets.
Hi Sheekanth and Francis,
This is a little late but thought I could provide an additional perspective to this. We take the following approach:
1) Applications are logical representations
We do not represent physical representations, deployments, or environments in Application Factsheets.
This also follows the ServiceNow Common Services Data Model (CSDM) definition of a "Business Application". The ServiceNow definition of a business applications is (paraphrased) "A single, logical representation of an application regardless of its instances or environments".
Modeling in this manner also aligns with the way our business users think about applications.
2) Use IT Components for servers, locations, and environments only when needed
We try to not track too much physical detail in LeanIX as that is the responsibility of our ServiceNow/CMDB. Currently, we represent virtual servers as IT Components when there is a need to do so. In this manner, we also leverage the ability to specific location. For example, for technology refresh efforts pertaining to MS Windows Server 2008 or for data center and LAN closet moves. We are contemplating storing all servers eventually so that this important relationship, app to tech stack, can be properly and effectively managed by the application owners.
3) Use Application Parent-Child Hierarchies Sparingly
Just to keep things simple, we encourage using parent-child hierarchy for applications only when needed. Specifically, if the parent is considered a "suite" and each child application can stand on its own, independent of its peer children, and if SOME of the child applications have regulatory requirements, then a parent-child representation is appropriate. As an example, our ERP solution suite has an Accounts Payable/Receivable module and a Site Location Master Data module. The former requires SOX controls as a KFA while the latter has no SOX requirements. We are also doing this for applications that use our Snowflake Cloud where some have GDPR requirements while others do not.
I fully expect other scenarios to arise but this is what we have in place right now and will adjust as needed.
Hope this helps.
Regards,
Mark
We're currently reviewing our definition of a parent-child application relationship. As we built things out over the years, the definition drifted and we have multiple meanings... so, we're trying to clean it up. I like Mark's suggestion about using them sparingly because they can be very constraining in data flow diagrams. Representing applications as logical entities makes sense as Mark outlined. I believe the relationship should only be used to subdivide applications into functional components that can truly be added or removed from the application suite. PeopleSoft is a good example. If you want to have separate instances of applications, then I'd keep them separate and use technology components to relate them to one another (shared runtime environments for example).
Regards,
Peter
