The Application Layer of the Essential Meta Model is concerned with the behaviour of the systems that are in use in the organisation - i.e. the functionality that they provide. This tutorial introduces the Application Layer and gives an overview of the main constructs available for modelling Application Architecture.
As with the other layers of the core meta model, the Application Layer is split into the following views:
- Conceptual - where we define the ‘what’. In application terms this means ‘what’ application capabilities are required within each business domain, for example, in a Retail Sales organisation, Manage Warehouse is an application capability required by the Fulfilment business domain. Note that this does not touch on how this capability is provided, purely what is needed. The ‘what’ is necessary to understand what capabilities your applications need to provide and is separate from how these capabilities are provided.
Note that in many cases, application capabilities will often mirror business capabilities found in the Business Conceptual Layer. This reflects the fact that application capabilities may be provided to support or even fully realise business capabilities.
- Logical - The logical area is where we define the ‘how’. In application terms this is the lower level abstraction of ‘how’ the ‘what’ will be achieved. These will consist of things such as what functions applications need to provide to realise the capabilities and the detail of the application that provides these functions. In this area it is also possible - although not mandatory - to group the functions into services. This is useful if you are looking to introduce a service-based approach to delivering and managing your application portfolio.
- Physical - The physical is the actual implementation or deployment. In application terms this means the actual deployments of applications that provide functions or services.
The major constructs for capturing Application Architecture elements are shown in this diagram. The following definitions describe and provide some examples of each construct.
- Application Architecture Objective - A strategic goal associated with the Application Architecture of the enterprise.
- Example - We will minimise the degree of overlap of functionality across our application portfolio.
- Application Architecture Principle - High level rules that govern the manner in which application capabilities are delivered by the enterprise and provide the context for designing and defining how these capabilities will be realised.
- Example - We will purchase packaged products, rather than build applications ourselves
- Application Capability - Application Capabilities provide the abstract perspective on the functional behaviour required to support the business, i.e. what application functionality will be required to support the Business Processes.
- Example - Manage Customer Information, Manage Warehouse, Process Orders, Take Orders, Asset Allocation, Order Management, Settlement Management.
- Application Service - An Application Service is a well defined component of functional behaviour that provides a logical grouping of Application Functions. This is useful, particularly if you are looking to introduce a service-based approach, but this approach is not mandatory. However, the Application Service enables you to capture how you plan to structure and provide application functionality - defining your 'ideal applications' - before selecting, the ‘real’ applications that you will buy or build to fulfil these Application Services. The specification of the service, in terms of what it does, is defined by the set of Application Functions that it provides.
- Example - Online Storefront, Order Management System, CRM System, Warehouse Management Systems, Exchange Rate Service, Credit Card Payment Service.
- Application Function - A discrete piece of functional behaviour that an application provides.
- Example - Generate Order List, Generate Picking Ticket, Log Picked Item, Release Order for Picking, GetAllExchangeRates, MakeCreditCardPayment, Calculate Client Risk, Create Order, Update Account Details
- Application - Provides a means to group a set of independent Application Providers (i.e. modules) that are ‘badged’ under a single name. Applications contain a set of one or more Application Providers and allow you to model the fact that a number of specific providers are known as an Application, e.g. an installation of SAP R/3 containing the FI, CO, SD and MM modules could be grouped using an Application called 'SAP'
- Example - SAP, Oracle, Siebel, WSMS
- Application Provider - An Application Provider is a real system (or component of) that delivers functional behaviour to the organisation. It provides one or more Application Services and to provide a service it should, through its Application Function Implementations, provide all of the functions that the service has defined. Application Providers capture both the specific installations of a 'packaged application' that is used in your organisation and bespoke systems that has been developed in-house.
- Example - MyCompany's Oracle Financials, The SAP Finance System, The SAP Warehousing System, MyCompany's account of SalesForce.com.
When capturing packaged applications, it is important not to confuse the application - the functionality - with the software product (Technology Product) that you have purchased to deliver this functionality. However, it is common for organisations to refer to an application by the name of the software product, especially when there is only one instance of it in the company. e.g. an installed of SAP R/3 (the Technology Product) is commonly called 'SAP' (the Application Provider).
- Application Function Implementation - Application Function Implementation capture the specific functional components or operations of an Application Provider and implement Application Functions. To capture these, it is common to use things like particular screens, menu areas or interfaces of a packaged application.
- Example - Oracles Financials::Update DD Postings; SAP BW::Generate Order List
- Software Component - A [typically coarse grain] discrete software component that is contained within the logical software architecture of an Application Provider that provide specific Application Function Implementations. The intention here is to capture dependencies on the software components of an Application Provider, and not to provide detailed UML-style modelling of the Software Architecture. Software Components are 'packaged' with other components as part of an Application Deployment to enable us to understand how the physical - often distributed - deployment of the application affects how the functionality is delivered.
- Example - SAP R/3::Server; SAP R/3::GUI; Oracle Financials::Server
- Application Deployment - A physical deployment of an application that exists in the organisation, e.g. Production Environment, Testing Environment. Application Deployments provide the means to capture the specific instances of an Application provider and the dependencies that exist on Technology elements and also between the functionality that is supporting processes and a particular instance of an application. Each Application Deployment is defined in terms of the Technology Architecture that it uses and the set of Software Components that are contained in the deployment, which enables complex distributed applications to be accurately modelled.
- Example - SAP BW::Testing Environment; SAP WM::Training Environment; SAP BW::Production Environment