;

Application Modelling

8 min

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:

  1. The spreadsheet document

  2. The personal database project file (which would include forms etc.)

  3. The word processor document (perhaps with macros in it etc.)

It is important to note that the tool should have some specific support for a process, so you probably wouldn't model a simple Word document to write a strategy paper, but a macro-drive Word document that a client completes as part of client-onboarding that is scanned into another system, may be modelled. You may want to name it meaningfully, e.g. Client Onboarding Document – Word.

For things like Business Intelligence tools, where the output, like reports, can be created ad-hoc by end-users, the Application_Provider is:

  1. The cube/universe etc.

  2. Pre-defined report

TIP: Don't get too hung up on these, only pick the most important ones, so we would advise you don't document, for example, every single pre-defined report in your BI system – unless you are looking to do something of real value with the data.

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.

You may want to add context to the name, e.g. a deployment of Oracle financials may exist in London and Singapore, so using a name such as 'Oracle Financials – Test' could lead to two different deployments with the same name, so consider the name based on the scope of your organisation, e.g. 'Oracle Financials – London' and 'Oracle Financials – Singapore'

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:

  1. A different owner [a split in common code could occur at some point, even if it hasn't already]

  2. Separate functional configuration

As an example, an organisation in London and Singapore may have an on-premise HR system in each site, Oracle HR. However, each manages its own instance, deployed locally and configures it to its needs. In this case, they are effectively different applications so we would model these as two application providers.

Otherwise, create two Application Deployments of the same Application Provider

In the above example, both use Oracle HR and have identical configurations, controlled centrally, any changes are deployed to both. A user in London could work on the Singapore instance and wouldn't notice any difference in configuration from the London instance. This is a single Application deployment with separate deployments.

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:

  1. Modules of the Application Provider

  2. Looking at the homepage of an application and looking at the links it has

  3. Identifying specific, named transactions or screens in the Application

  4. Looking at any API operation names

Updated 31 October 2023

Contact Us