Application Modelling Overview
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.
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 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 – Manage Customer Information, Manage Warehouse, Process Orders, Take Orders, Asset Allocation, Order Management, Settlement Management
- 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
- 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.
- 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
- 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 1 November 2023