What is an Application Provider?
An Application Provider is something, such as a real system (or component of), that delivers functional behaviour to the organisation. In Essential an Application_Provider usually equates to an application, but it could also be an API or a middleware integration. Note we have a separate sub-class for APIs in version 6.4 onwards.
Sometimes it's really easy to identify something as an application, e.g. a business system that you use in support of specific processes, e.g. Oracle HR, Workday, Salesforce CRM. However, some of the tools that we use every day, such as Office-type tools, or BI tools, can also be used to support a process or provide Application Services.
What's the Application Provider in these cases?
For Office-type tools, the Application_Provider is:
The spreadsheet document
The personal database project file (which would include forms etc.)
The word processor document (perhaps with macros in it etc.)
For things like Business Intelligence tools, where the output, like reports, can be created ad-hoc by end-users, the Application_Provider is:
The cube/universe etc.
For integration tools and solutions, it is the deployed 'project' for the integration that is the application provider.
Naming Application Deployments
Naming is important but not always easy. An Application Deployment represents the package of software components that are deployed [as instances] to Technology Nodes to create a physical instantiation of the Application.
If it's a single application it is supporting, then name the deployment from the Application Provider that it's a deployment of, if it is the deployment of several components then give it a name that encapsulates those components, but avoid using simple names such as 'EAR', 'WAR', 'package', 'Archive' etc. which don't provide much context to the person looking at a deployment.
When to choose an Application Provider or Deployment?
It is not always clear at the application level as to when two uses of an Application Provider should be captured as either two deployments of a single Application Provider or as two separate Application Providers.
The following guidelines should be followed, create two separate Application Providers if an Application Provider is used in two different areas of the enterprise and has:
A different owner [a split in common code could occur at some point, even if it hasn't already]
Separate functional configuration
Otherwise, create two Application Deployments of the same Application Provider
Defining Application Function Implementations
Application Function Implementations model the specific modules, transactions, screens etc. of an Application Provider to capture, at a finer grain, the functionality that the Application Provider provides.
To identify an Application Function Implementation, we suggest using:
Modules of the Application Provider
Looking at the homepage of an application and looking at the links it has
Identifying specific, named transactions or screens in the Application
Looking at any API operation names
Updated 31 October 2023