Application Design Principles

A key tenet of System Design is to avoid duplication of processing logic, data and the technology platforms that are required to support them, which has the following key benefits:

• Ensures Consistent Processing
• Maximises Data Integrity
• Maximise Design Flexibility
• Maximises Re-use
• Minimises IT TCO

To achieve these goals an Application aims to deliver a discrete set of Functionality, and that encapsulates the underlying Data associated with that Functionality.

Applications requiring or updating information owned by another application typically do so via interaction with component on the owning application rather than directly accessing the data.

An Application should ideally not be constrained by:

• The User Groups and Channels that it must support
• The Technology Platforms that are required to deliver the Software Components
• Delivery concerns: e.g. programme structure, organisation, etc.

Applications requiring or updating information owned by another application typically do so via interaction with component on the owning application rather than directly accessing the data. Application interfaces may be in real time or via batch / scheduled processing that may do this via a common integration layer. Refer to Integration Principles for more details.

It is important that application components are firstly defined based on the functionality to be supported since there often a tendency to demarcate components based on the underlying technology platform. If the design is based on platform boundaries then this results in the application abstraction layer not being realised in the software, which results in more tightly coupled / monolithic functionality and duplication across platforms.

Any given functionality should be encapsulated within a single application, but within that application it should be implemented separately from other functions. Functionality should also be abstracted from the platform technology, noting that it may be delivered across more that one platform (e.g. to support both presentation and service logic).

Whilst there will be dependencies between functions, in particular to deliver end-to-end processes, these should be abstracted away from the individual functions where possible – for example into process control components. It is also important that processing supports error and exception management to help minimise functional dependencies where possible. Given that a function may support multiple processes, and may need to deliver tailored functionality to each, common processing should be identified and tailored processing separated within the function.

Therefore a holistic view of the functional design should be maintained in order to be able to identify and manage components that are a common across multiple different initiatives.

Applications can support various Process Styles that support different behaviour and require specific supporting Application Frameworks:

• Online Transaction Processing - Maintenance of discrete items of information in real time involving end user interaction.
• Batch Transaction Processing - Maintenance of bulk information, typically scheduled and not involving end user intervention.
• Analytics - Analysis of information to generate insight and reports. May be processed in real time or batch.
• Integration - Exchange of information between applications, via messages or bulk data transfer.

These may be supported by various data/content management and persistence services.

Online applications are not separated based on the User Service Classes (combination of user group and channel) they support but on the capabilities they deliver to these. This approach is important in order to ensure that capabilities are delivered consistently across all the User Service Classess supported.

Similar to the key concept of delivering consistent processing across the User Service Classes and associated channels that an Application serves, it is also important to deliver a consistent Look and Feel across all of the Applications delivered over a given channel.

Application Design supports consistent Process and Activities across channels whilst the Channel Design supports consistent Look and Feel across Applications.

Whilst a common look and feel can be achieved through design it may be only be actually realised through common platform presentation cervices to facilitate consistency and integration. However, whilst this is a valid approach for the Platform Design, the logical Application design must define proper separation between Applications irrespective of this.

There are options for the way that business activities are delivered to support online processing, as illustrated below. A more granular approach where each business activity is considered a logical unit of work is generally recommended where possible. Note that the Service Control layer defined above typically relates to the physical transaction boundary in the Platform Design, since it generally manages persistence of the outcome of the logical unit of work.

Batch transactional processing differs from online transactional processing in two key ways:

• Multiple instances of the same type of transaction are processed together
• There is no user interface

Key design considerations include:

• Checkpointing - Each transaction may not be committed independently, but rather as a group in order to promote efficiency (transaction commits are expensive). However, should a failure occur following a checkpoint it should be possible to restart the process at that point.
• Skip - Some failures should be able to be skipped automatically and analysed later in order to avoid operator intervention.
• Change of Key Processing - When primary or secondary keys change then additional processing may be appropriate – e.g. to record a total for multiple financial transactions for a given consumer
• Sort & Split - To support the above and to enable parallel processing it is necessary to be able to sort and split transactions.

Whilst Transaction Processing services focus on managing data integrity, Reporting & Analytical Services are focused on:

• Deriving Information & Knowledge Production
• Calculations
• Making Decisions
• Information Formatting (for Reporting)

Their are a variety of Application Frameworks to support this processing depending on the specific requirements, including Business Rules, Business Intelligence & Reporting, and specialised Expert Systems. Some of the features of these may include:

• Domain-specific language & information structures
• Decision Making Capabilities:
• Inference (forward chaining / fact driven & backward chaining / goal driven) & Event-Condition-Action
• Specialised algorithms, e.g. Rete pattern matching
• Maintain state of facts and associated conditions that have been met
• Analytical / statistical models: Predictive, Descriptive
• Models Types: Regression, Time Series, Machine Learning/AI
• Online Analytical Processing & Data Mining
• Knowledge Management

There are generally two types of report processing:

• Static – pre-defined datasets and limited dynamic report formatting.
• Ad-hoc – dynamically defined datasets and report formatting, typically support by Online Analytical Processing (OLAP) solutions that provide the capability to drill down/up, slice and dice, and interrelate data using business structures and terminology

Static reports are typically delivered by IT, however the relatively low complexity and independence from transaction processing allow the approach to be adapted to minimise delivery timescales

Ad-hoc reporting is typically undertaken to meet the dynamic demands of specialised teams with Finance, Operations and Marketing. These may be delivered by specialist teams that may involve IT for some aspects.

There are also different types of reporting functionality:

• Client Reporting – client account and tax statements, advices, proposals and notifications (but not including general correspondence); these are typically static, although some flexibility may be required to incorporate tailored information (e.g. marketing messages). Some may also require very tailored solutions, such as for region specific tax statements.
• Management Information (MI) – also known as Business Intelligence, provides reports to support general management decision making; many of these which may be static, but there is typically a need for ad-hoc processing
• Operational Reporting – reports to support operational business processes, which are often associated with a specific application; there may be some need for ad-hoc but typically these are static and typically executed against the production database if required to present up to date information, or a copy of this.