The Platform Design translates the Application Design into the physical Application Software. Application Software is supported by System Software, which provides the general computing environment (e.g. operating system, application server platforms, RDBMS, etc.).

Application Software can be defined in terms of Processing Layers, which deliver different Processing Styles. A physical Application may be defined by the Processing Styles it supports, e.g. the Customer Contact Online Application or the Customer Contact Batch Application.

Application Components generally refer to a large grained software artefacts that groups related functionality, typically for a given Processing Style. Components should therefore be aligned with functional capabilities, and data in the case of ETL and OLAP.

Refer to Application Design Principles for more details of functionally orientated application design principles.

The Application Processing Layers and associated Components may be supported by a variety of different Technology Platforms deployed across different infrastructure layers.

This is further illustrated in the following application example.

System design describes processing across three logical processing layers – User Interface, Process Control and Service. Ideally these layers would be delivered by a single set of components that reside in only one of the physical processing layers, for example:

However, in reality this is not practical since:

• Service logic needs to be implemented alongside the physical user interface in order to deliver usability and performance.
• Process Control is easier and more efficient to deliver close to the point of user interaction management.

Therefore the mapping of logical processing layers is actually typically more complex.

For example, consider the product selection activity.

To enhance usability and efficiency the product selection validation will be executed by the client based Presentation Services processing layer.

However, note that this does not make this processing part of the User Interface logic! It is still Service logic, it simply happens to be deployed on the client.

Whilst it may be argued that simple single field validation based on enterprise data standards is within the scope of the User Interface, however cross field and feasibility validation is certainly not, and is firmly within the scope of the logical Service layer.

Even though service logic may be delivered across all the physical Processing Layers of the Application, it is imperative that the logical processing layers be separated out in the physical implementation.

Of course, it may be challenging to achieve this level of separation depending on the underlying technology platform, however appropriate use of software separation strategies such as libraries, snippets etc. can support this approach.

This may seem to be in conflict with the concept of Service Orientated Architecture where that equates to a view that “services are deployed on servers”. However this view is typically not how most applications are delivered, and in any event the approach is in keeping with the key principle of SOA around separation of service logic with clearly defined interfaces.

Given that Service logic is typically deployed across all of these processing layers, it is imperative that the different groups responsible for the delivery of these layers agree on a the logical application design prior to development of the physical software.

An approach where Service and Process Control logic is tightly coupled with User Interface logic is more aligned with the approach to deliver granular activities where the activity delivers an atomic unit of work.

Whilst this accepts a high degree of functional coupling between Logical Processing Layers within an Activity, they should remain physically separate.

The Service logic deployed close to the User Interface is essentially a proxy to the Service logic deployed on the Business Services layer and should ideally be reflected in the Service logic deployed on the Business Service layer so that this truly encapsulates the underlying data, supports all potential channels and can even be invoked independently.

The Service Control layer on the Online Business Services layer typically reflects the physical transactional processing boundary.

This approach is illustrated in the updated application example.

The channel design goal for a consistent look and feel and integrated user experience as well as the application design goal for of delivering consistent information and functionality (refer to Application Design Principles influence the user interface implementation approach and which may be addressed through the Portal concept.

A Portal is a concept that essentially enables the bringing together channel specific design goals, application specific functionality and application / process integration, however as a result the software delivery approach is more complex.

The portal achieves this by delivering application presentation services on a common technology platform, supporting a common look and feel and application integration at the user interface level. Typically it does not aim to replace the entire application user interface, but instead provide limited views that link to broader functionality provided by the application specific user interface. The application views can also link to one another to provide a degree of integration, however it's important that some logical separation is applied between views.

Some so-called “portal” initiatives may in fact be focused on the delivery of a unified (typically web technology based) cross-application user interface. However this approach may be in conflict with a more general multi-channel strategy to deliver centralised processing that is channel independent. In addition, there may be significant effort to migrate existing applications into the Portal framework.

Therefore, it’s important to separate the portal concept from broader use of portal technology. This is whilst the portal technology may be used to deliver application user interfaces services it may support some, all or none of the Portal concept.