The Application Provider class is used to capture the applications that exist in the organisation. So named, because they provide implementations of the Application Services, this one of the most complex elements in the Essential Meta Model. This tutorial introduces Application Providers and describes how to capture the various architectures that are associated with them.

Logical View of Applications

Application Providers are used to model the applications that exist in the enterprise. These are logical constructs that define the relevant details of an application in the general case. Specific instances of an application are defined via the Application Deployments.

In Application Architecture, we are concerned with the functional behaviour of the systems that are in use in the organisation. Technology used to implement this functionality is managed in the Technology Layer but is related to the Application Provider through its Technology Architecture.

Basic Definition

Creating a new Application Provider instance in the repository is very easy. Create a new instance, navigate to the Application Provider class - which is in the Application Provider Types - in the Class Browser panel of Protege and use the , button in the Instance Browser.

• Give the Application Provider a name. Normally, this is the name by which your application is known in your enterprise.
• Add a description of the application
• Map the Application Provider to the Application Service(s) that it provides, using the button.

Careful analysis of the application is worthwhile to understand both how it is being used, and how it is deployed. It may be that you need to create more than one Application Provider and group them using an instance of the Application class.

Application Function Implementations

Application Function Implementations implement Application Functions that are defined in the higher level of the Logical Application View.

Define Application Function Implementations to capture the finer-grained functional modules of the application. Application Function Implementations can have a dynamic application architecture defined for each to capture the dependencies that exist when that Application Function Implementation is executed.

Static Application Architecture

The Static Application Architecture is used to capture the static dependencies that exist between Application Providers. e.g.

• Data dependencies - Application_1 depends on Application_2 for a feed of data
• Functional dependencies - Application_1 invokes Application_2

Static Application Architectures are defined in the same way as other architectures in Essential Architecture Manager. For more information, see Working with Architectures.

Support Business Processes

Capture the Business Processes that the Application Provider supports by creating new instances of the Physical Business Process-to-Application Provider relationships.

Technology Architecture of an Application Provider

From the Application Layer, we can define the Technology Architecture of an Application Provider – an actual application that is being used to provide an Application Service – in terms of the types of technology that should be used. In this architecture, we capture a Technology Component Architecture to define the technology elements and the dependencies between them.

A Technology Composite provides the definition - the black box - for the Technology Component Architecture, we can also specify the actual builds of technology products that are available (or will be) in order to deliver this Technology Composite.

We separate these two Technology architectures (Technology Composite Architecture and Technology Product Build, respectively) to enable these two different levels of abstraction to be captured. What this means is that we can define the Technology components that we require in order to run the application and then separately describe how this component architecture is delivered in e.g. the development environment differently to that of the production environment.

In addition to the Logical views that are described above, we can capture the required Technology Capabilities of an application, which defines the high-level technology requirements of the application (as shown in the diagram, left). Essential provides reports that review these requirements and evaluate the Technology Architectures to demonstrate how these requirements are being met – or not! Typically, these requirements would be captured before the Technology architecture is defined and would be used to drive that activity.

How Applications are constructed – Software Architecture

The high-level software architecture defines the software components that deliver the application. This can be a very coarse-grained model and for packaged applications may only consist of a single software component.

We capture the software architecture to enable us to accurate understand how an application is physically deployed. In the physical view, it is the deployed software components that are the physical manifestation of the application.