This covers the architecture guidelines for enterprise applications in the aspects of Application, Integration, Infrastructure, Standardization, Security, Performance, reliability.

1. Architecture Governance
- Enterprise Application Guidelines
Guru Lakshmeekar Boggula

2. Objectives
• To select / create a structured solution that meets all of the technical
and operational requirements, while optimizing common quality
attributes such as performance, security, and manageability.
• Create a candidate baseline architecture for the solutions
• To understand the underlying architecture and design principles
and patterns for developing / selecting successful solutions.
• Choose the standard technologies and mechanisms for the solutions
• To improve the quality of the resulting architectures.

3. Reference Application Architecture

4. Generic Application Standards /
Architectural Requirements
• Architectural Best-Practice requirement: The proposed solution should have a layered/multi-tiered
architecture with clear separation of concerns. A prerequisite to enable the entire solution to be highly
scalable at each of the layers constituting the solution (e.g. Web/Presentation, Application/Business-
Logic, Data/DB).
• Proposed solution should be built on a standards-based platform. If vendor has any recommendations on
any specific hardware/software platform/framework, the same should be substantiated with statistics of
performance capabilities of the proposed solution, on that platform.
• Standard Logging and mechanism is to be provided by the proposed application that supports flexible
levels of traceability of control flow within the application (to facilitate issue resolution) as well as
auditability (particularly relevant and mandatory for applications that originate financial transactions of
any form).
• Proposed systems’ database should be supported by a Data-Dictionary that allows the Bank to derive the
required operational and analytical data from the underlying database to meet standard MIS
requirements.
• Follow the best practices like Do not duplicate functionality, Establish a coding style and naming
convention etc.
• Flexibility to support Digital / Mobile / RWD /AWD will be added advantage.

5. Integration Requirements
• Where relevant, the proposed solution should be capable of supporting any of the following standard
methods for integration with our backend for online-real time calls.
– JDBC-API
– Web-Services API
– REST-based API
– JSON based API
• Where relevant, the proposed solution should also be capable of also supporting Web-Sphere MQ – API
based integration with any of the existing systems/solution for message-based interaction
(asynchronous-integration)
• For any requirement pertaining to offline-batch processing scenarios, the proposed solution should also
support, a flat-file based data exchange interface that guarantees security, integrity and reliability of data
in regards to the data-transfer mechanism (to and from the Core/target system)? Particularly, data
exchanged through flat files should have a mechanism to detect any potentially malicious tampering of
data while in transit. Extract upload functionality should include capability to notify exceptions (upload
failure, extract validation failure etc) to operational teams via e-mail. Note : Bank provide a set of utility
tools/libraries (Java based) that handle checksum generation and validation. Proposed application
should be capable of integrating with it.
• The proposed solution should be able to interface with E-mail infrastructure to enable dispatch of
notifications (intended both for business and operational purposes) via e-mail.
• Proposed solution should allow to fetch the data from it’s database for the reporting / analytical etc.
requirement

6. Infrastructure Requirements
• Proposed solution should support deployment on standard Application Servers like
WebSphere, WebLogic. Support for Open-Source Application Server platforms like
JBoss, Container Frameworks like Apache Tomcat / Spring etc. would be an
advantage in scenarios not involving transactional functionality within the underlying
application.
• It should be possible for the proposed solution to be hosted on standard
Virtualization platforms like VMWare, LPARs, OracleVM (in case there is
dependency on Oracle DB).
6

7. Scalability and Performance
Requirements
• Based on the projected user-base (to be provided by business) and concurrency levels expected
within the application, the vendor should be able to provide recommendations on hardware sizing
and capacity that is needed to handle average and peak loads for the proposed system.
• The proposed application should support techniques that ensure optimal utilization of network
bandwidth (e.g. use of AJAX, cache) where appropriate and necessary.
• The proposed solution should support both horizontal scaling (adding more servers) as well as
vertical scaling (adding more resources e.g. mem, cpu, disk-space etc) of servers as needed.
• The architecture of the proposed system should support deployment architecture that can handle
load-balancing and failover requirements to ensure optimal response time and maximum
availability without server affinity of sessions (i.e. user session related data should not be server-
sticky).
• The implementation of the solution should be based on sound design and development best
practices that address :
– Connection pooling/Optimal resource management
– Thread synchronization (where applicable)
– Transaction management (ability to guarantee data integrity and consistency across exception
scenarios)
– Caching for optimized performance
– Garbage collection (orderly release of resources) for optimal memory usage
7

8. Maintainability and Reliability
Requirements
• The proposed solution should support extensive alerting capabilities (e-mails/SMS-based)
to notify operational teams about different categories of errors and failure scenarios within
the solution for immediate resolution. This facility should be easily configurable.
• All batch interfaces (file-upload/download/extract based interfaces) of the proposed system
should be capable of validating integrity of data (checksum, hash totals etc) using some
standard mechanism. It should also be capable of generating detailed report upon
completion of a batch operation that will enable easy detection of any intermediate failures
during the execution of the interface (with alert/notification capabilities where required).
8

9. Deployment Architecture - Security
Requirements

10. Security Requirements
• The proposed solution should support LDAP authentication to enable users to get authenticated
against LDAP/ Active Directory to support single-sign on capability for domain authenticated
users.
• If integration against LDAP is not possible, the proposed solution should support implementation
of flexible security policies that can comply with the requirements like
– password should not traverse the network in clear-text
– password complexity enforcement
– automatic lockout after multiple incorrect retries,
– automatic password expiry after preconfigured time
– multi-factor authentication (e.g. RSA-based integration or Soft-token based integration) for
specific privileged functionality within the proposed solution, if necessary
• Where applicable, the proposed solution should have undergone security testing from an
independent agency that has certified the solution for standard web-application security
vulnerabilities. This is particularly applicable for applications that have Bank customer facing
functionality and/or accessed over the Public Internet.

11. Thank You