Application Modelling Overview

12 min

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, examples:
    • In a retail sales organisation, Manage Warehouse is an application capability required by the Fulfilment business domain
    • In an asset management firm, Manage Corporate Actions would be a capability required in the Operational domain
    • For a travel firm, Manage Bookings would be a capability we may have

 

Note the names do not touch on how each capability is provided, purely on 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.

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 applications that provide services and functions to realise the capabilities. In this area, it is possible – although not mandatory – to group the functions into services.
  • Physical – The physical is the actual implementation or deployment. In application terms, this means the actual deployments of applications that provide functions and/or services.

 

Cdf 7f3b1rbieewhew2uo Apparchhlmetamodel

The major constructs for capturing Application Architecture elements are shown in this diagram. The following definitions describe and provide some examples of each construct.

Conceptual Layer

  • 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 how 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 – Customer Information Management, Warehouse Management, Order Processing Management, Order Acceptance Management, Asset Allocation, Order Management, Settlement Management
TIP: When defining your application capabilities, ignore your applications on the first iteration and describe the application capabilities you would need to deliver by looking at your business capabilities. Ask yourself, ‘What applications capabilities would this business capability need?’. Once you have exhausted that approach, consider the capabilities your existing applications provide and see if you have any gaps.

Logical Layer

  • Composite Application Provider– Provides a means to group a set of independent Application Providers (i.e. modules) that are ‘badged’ under a single name. Composite Application Providers contain a set of one or more Application Providers and allow you to model the fact that several 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
TIP: In Essential this is captured as a Composite Application Provider, note, that although we have the Application_Provider class, we recommend just using Composite_Application_Providers for all applications.
  • 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 have been developed in-house.
    • Example – MyCompany’s Oracle Financials, The SAP Finance System, The SAP Warehousing System, MyCompany’s account of SalesForce.com.
TIP: 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).
TIP: Note the previous tip – we recommend using the Composite_Application_Provider class for all applications.
  • Application Service – An Application Service is a well-defined component of functional behaviour that provides a logical grouping of Application Functions. 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 Function Implementation – Application Function Implementations 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 – Oracle 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 provides 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

Physical Layer

  • 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, 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

Updated 16 April 2024

Contact Us