Application Design Guidelines Sample

1 Application Design Principles

1.1 Design Application to be Loosely Coupled - The design shall be highly granular and loosely coupled, and support the possibility of “re-partitioning” of the application in the future. This is to cater to the ever-changing business needs.

1.2 Design Application - Application shall be designed with SOA or microservices architecture.

1.3 Ease of Use - Application shall be easy to use and make the underlying technology transparent to the users.

1.4 Design for the N-tier Service Oriented Architecture - The design shall support an N-tier service-oriented architecture that is highly scale-able and be easily modified to support changes in business requirements.

1.5 Do not Focus on Platforms or Deployment - The System shall be in highly portable codes so that it can be transferred with minimal changes from one computer system to another. Platform-specific or hard-coded interfaces that are difficult to change shall be avoided.

1.6 Generalize Application Interfaces - Avoid assuming a specific page size, page format, layout language or user language whenever possible.

1.7 Implement Business Rules as Discrete Components - Business rules shall be implemented as discrete executable components or services.

1.8 Utilizing Off-The-Shelf Components - The System shall utilize off-the-shelf components whenever possible.

1.9 Design for Manageability Design applications so they can be managed using the enterprise’s system management practices and tools.

Applications and their components require the following management functions:

a) Software distribution.

b) Start-up, shutdown, and restart of components.

c) Starting multiple instances of a component.

d) Configuration of components.

e) Logging of component operations.

f) Communication of errors, exceptions, and unexpected events.

g) Security.

h) Installation, removal, and update of application modules.

i) Version control.

---

1.10 Adopt Coding Standards

1.10.1 Provide coding guidelines and standards for review.

1.10.2 Shall fully comply with the Secure Coding Standards.

If any of the clauses cannot be complied with, the provider is required to perform a security risk assessment and propose alternative controls to mitigate the risks to a level that is acceptable by the Customer.

1.10.3 The provider shall provide an industry-recognized static code analysis tool which they own, to check and identify known errors, vulnerabilities and weaknesses on all Application Software (including mobile codes or applications such as browser plug-ins, client-side scripts, applets, smartphone apps, etc.) developed by the provider at no additional cost to the Customer.

1.10.4 The static code analysis tool shall minimally perform the following:

a) Automated detection of Open Web Application Security Project (OWASP) Top 10 web application security risks;

b) Fully integrated into the Integrated Development Environment (IDE);

c) Highlight source code areas that will have a potential performance impact and will pose security vulnerabilities; and

d) Recommends and implements remediation actions for both performance findings and security vulnerabilities.

1.10.5 The Supplier shall use the static code analysis tool to perform and carry out secure code reviews.

All security findings rated Medium 1 and above shall be resolved prior to code check-in.

1.10.6 The Customer may request the provider to perform manual code reviews if the static code analysis tool is not able to detect certain security vulnerabilities.

Such manual code reviews shall be at no charge to the Customer.

1.10.7 The provider shall train and advise the Customer Representative(s) on the static code analysis tool so that the Representative(s) can effectively verify the results of the review. Such training shall be at no charge to the Customer.

1.10.8 Design for Proactive rather than Reactive Management - With proactive application management, the application system can report a “potential” problem when a certain pre-defined threshold is reached.

This allows the users/administrators to act appropriately before the actual failure occurred.

1.10.9 Design to support Knowledge Management Application shall be designed to support both asynchronous and synchronous collaboration. It shall integrate with the Portal solution and Collaboration Tool to provide presence awareness, instant messaging and web conferences.

1.10.10 Design for End-to-End Management Application shall be managed in its entirety, i.e. all components of the application and their associated dependency must be managed. Application dependencies also include infrastructure (e.g. messaging infrastructure, network etc), other application systems or shared components/utilities.

1.11 Design System to Provide Information for Application Management 1.11.1

The System should reports statuses like performance statistics, availability statistics.

At design time, parameters that need to be monitored must be defined. For example, when database tables reaches 80% full, the Database administrator should be alerted to take corrective action before user experience application outrage.

1.11.2 If there are no automatic tools for management, the system shall generate log files that can be managed and monitored by administrators. Appropriate run-time tracing may be implemented to assist in troubleshooting. These tracing shall be turned on or off by the administrators.

1.12 Application shall be designed to facilitate management.

The System design shall be parameter-driven so that the application can be “reconfigured” without impacting the users operation.

2 Business Process Modelling

2.1 Business Process Execution Language - Business Process Execution Language (BPEL) specifies business process behavior based on Web Services, and enables task-sharing for a distributed environment.

BPEL is used to model the behavior of both executable and abstract processes.

The scope includes:

i. Sequencing of process activities, especially Web Service interactions

ii. Correlation of messages and process instances

iii. Recovery behavior in case of failures and exceptional conditions

iv. Bilateral Web Service based relationships between process roles

2.2 Business Process Modelling Requirement - The provider shall use BPEL to model the business processes as part of the detailed requirement study.