Business Application: best practices

jna2756
Tera Expert

Hi all,

 

We're working on refining our CMDB and making sure everything in our environment is captured as required one of errors where we got a lot of conflicts internally is business applications. Can some people provide what are common examples of applications and what shouldn't be applications?

 

For example, I know an application like ServiceNow, ServiceNow ITSM, Salesforce, etc. are applications. However, are there any examples of things that some people might consider an application but shouldn't be consider a business application? some things that seem fuzzy to me is Microsoft Outlook, Apache, Cisco Prime wireless controller.

 

Thanks

Joshua Anderson

25 REPLIES 25

I agree with Mr. Whisperer - blanket statements aren't helpful, without context or explanation.

However, I think I understand where @scott_lemm is coming from here -- if you don't have a really good reason as to WHY you would track an individual desktop app as a "Business Application" it is best to avoid plunking that into the "cmdb_ci_business_app" table, due to the likelihood of unintended consequences (iykyk).

I agree.  I look at it from an EA perspective.  From their perspective if Desktop Software is how we provide a business capability, then I need to manage it just as any other business application.  It will be managed differently but it should still be managed.  That said, if your Enterprise Architects aren't using ServiceNow and you're not using Application Portfolio Management, you probably shouldn't worry about desktop software as a business application.


The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.

Hi @CMDB Whisperer 

Thank you for the opportunity to explain. 

 

The value proposition around Business Application lies in Application Portfolio Management (APM) and the future of Digital Product Management. The use, and thus the value, within APM lies in the relationships made to "instances of a Business Application" as represented in Application Services. These instances / Application Services are then tightly tied to ITOM capabilities of Service Mapping & Discovery to identify related infrastructure. TPM is a perfect example of how the data provided in each of these layers establishes a rollup value. All of these uses - Business Applications, Application Services, Service Mapping - assume a hosted environment such as a data center / cloud. They were never established for personal computers.

 

We do not support nor recommend the creation of PC software installation instances as CIs. That would explode the CI count exponentially in the CMDB. Often the use case for PC applications as CIs is for reporting purposes within ITSM as the work effort is on the PC hardware device for which these applications are installed. 

 

That said, an Application Service will never be created as a desktop software instance for a PC. Additionally, Service Mapping will never be run against an entry point found on a PC. Thus the stack as outlined in CSDM (Business Application -> Application Service -> Service Mapped CIs) is not established for PC Software. 

 

The above details are supported by the APM business unit. It is important to note that APM licensing, when enabled, will count all Business Application objects in their licensing formula. The management of objects that were not intended for APM / Business Applications, may have a negative financial impact. 

 

That is not to say PC software is not important or shouldn't be tracked. But the intention around APM and the Business Application stack was never for PC software. Users should not populate their locally installed PC COTS apps as Business Applications. 

 

The alternative is to establish PC applications as product models for request and SAM. These same product models may be identified as necessary in bundles where fat/thin clients exist but these PC apps are still not created as Business Applications. 

 

We are working on a Product Management capability using these product models as well as opening IPC to utilize product models in addition to CIs. Those efforts may help fill in the gaps. 

 

Again, thank you for the opportunity to provide some background. Feel free to reach out 1:1 to discuss further.

 

Thank you,

Scott

@scott_lemm I agree on all of the above.  Don't track PC software installations as CIs.  And don't represent them as Application Services.  At best it's a lot of overhead for very little to no value.  To manage and support the desktop software, focus on supporting the End User Compute CIs themselves.  That has always been my recommendation. 

 

On the other hand, if a business sees fit to identify a specific business capability as critical to their business and they want to use desktop software as the way to provide that capability, this still fits into the EA mission, and the CSDM schema.  All that is missing are the application services and other CIs, which again don't really matter since the only thing you are supporting in that case is the end users' computers.  And they know what those CIs are already!  

 

Bottom line, for most companies I agree that most or all desktop software falls outside the purview of enterprise architecture, and there is simply no reason to try and shoe-horn it into the CMDB.  But if  your enterprise architects want to include this in their application portfolio as part of capability management, and they are using APM, then it should probably be a business application so that they can manage it effectively.


The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.

Great explanation!

 


@scott_lemm wrote:

 

The value proposition around Business Application lies in Application Portfolio Management (APM) and the future of Digital Product Management. The use, and thus the value, within APM lies in the relationships made to "instances of a Business Application" as represented in Application Services. These instances / Application Services are then tightly tied to ITOM capabilities of Service Mapping & Discovery to identify related infrastructure. TPM is a perfect example of how the data provided in each of these layers establishes a rollup value. All of these uses - Business Applications, Application Services, Service Mapping - assume a hosted environment such as a data center / cloud. They were never established for personal computers.


This is the WHY part, that a business needs to consider before using the "Business Application" table. They may want to leverage features made available in APM and for that, need a piece of software in the "Business Application" table specifically, but if they're also using some certain features of ITOM, "it's gonna be a bad day" they may say...definitely a case of "more information required", in that instance.

In the OP, @jna2756 mentions "making sure everything in our environment is captured", which suggests that the desire to use the CMDB table is ITOM-based, more than APM-based...I could be wrong here, just a guess.