Cybage Software Pvt. Ltd.

High Level Design (HLD)

Document Name

<<Product Name>>
Version No.

x.x

Release Date

dd/mm/yy

Document ID

S
S//D
DE
EP
P//11..00//H
HLLD
D

This document of Cybage Software Pvt. Ltd. is for restricted circulation. No part of this publication
may be reproduced, stored in a retrieval system or transmitted in any form or by any means
recording, photocopying, electronic and mechanical, without prior written permission of Cybage
Software Pvt. Ltd.

<<Client Name>>
<<SystemName>>
HLD History

Ver.

Release

No

Date

x.x

Created By /
Modified By
and Date

dd/mm/yy

XY

Reviewed By

Approved By

and Date

and Date

Remarks and Changes Made

AB

Initial Draft

Distribution List
Sr.

Name

No.

1.
2.

XY
YY

3.

XX

4.
5.
6.
7.
8.
9.

AB
ZZ
LS
VC
RP
PR

QMS Ver. No: 1.0

Role

Organization Name

President
Senior VP of Technology
Vice President Business
Development
Delivery Head
Sr. Project Manager
Architect
Project Leader
System Analyst
Sr. Software Engineer

Confidential

Release
DD/MM/YYYY

Dt:

Client
Client
Client
Cybage
Cybage
Cybage
Cybage
Cybage
Cybage

Doc. Template Ver.

No. 1.1

Page 2 of 34

<<Client Name>>
<<SystemName>>
Table of Content

Introduction .......................................................................................................... 5
1.1

Purpose of the Document ........................................................................................................ 5

1.2

Objective of HLD ...................................................................................................................... 5

1.3

Scope of HLD ........................................................................................................................... 5

1.4

Acronyms and Definitions ........................................................................................................ 5

1.5

Reference ................................................................................................................................. 5

System Overview ................................................................................................. 6

2.1

System Overview ..................................................................................................................... 6

Design Considerations ......................................................................................... 7

3.1

Technology Consideration ....................................................................................................... 7

3.2

Identity Management ................................................................................................................ 7

3.3

Design Consideration for Development ................................................................................... 9

3.4

Single-Tenant Database vs Multi-Tenant Database .............................................................. 10

3.5

System IPR Decision Consideration ...................................................................................... 12

3.6

Rich User Interface Architecture ............................................................................................ 12

3.7

Design Consideration of Existing Application (IAS and Splendid CRM) ................................ 14

3.8

Design Consideration for the future provision ........................................................................ 14

3.9

Design should consider for partial offline model .................................................................... 15

3.10

Design Consideration of Application Performance and Scalability framework ...................... 16

3.11

Assumptions, Dependencies, and Open Issues .................................................................... 16

3.11.1

Assumption ..................................................................................................................... 16

3.11.2

Dependencies ................................................................................................................. 17

3.12

General Constraints ............................................................................................................... 17

3.13

Goals and Guidelines ............................................................................................................. 18

Organization of System ...................................................................................... 18

Architecture ........................................................................................................ 19
5.1

System Architecture ............................................................................................................... 20

5.1.1

Client Supplied Infrastructure ......................................................................................... 21

5.1.2

System Site Architecture................................................................................................. 22

5.1.3

High Level Technical Architecture .................................................................................. 23

5.1.4

System Logical Architecture ........................................................................................... 24

5.1.4.1

System Development Project Setup .......................................................................................... 24

5.1.4.2

Technologies Identified ............................................................................................................. 25

5.1.4.2.1

QMS Ver. No: 1.0

Exchange 2007 ..................................................................................................................... 26

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 3 of 34

<<Client Name>>
<<SystemName>>

Flow Diagram ..................................................................................................... 29

Design Limitations.............................................................................................. 29

Appendix ............................................................................................................ 30
8.1

Blue Whale CRM .................................................................................................................... 30

8.2

Evaluation of Sharepoint Portal Server .................................................................................. 30

8.3

Acroprint Evaluation for Time and Attendance ...................................................................... 30

8.4

High Level Design Document and their explanation for each component ............................. 31

8.4.1

Metadata Services .......................................................................................................... 31

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 4 of 34

<<Client Name>>
<<SystemName>>

Introduction
This plan will be used for managing all the High-level designs of project.

1.1 Purpose of the Document

The purpose of this plan is to

Identify different design approaches.

Identify core modules/sub-systems of the system and sub-system boundary.

Identify the best suitable technology for various sub-systems.

Identify areas that need R&D.

Identify third party components required in the system.

Identify components, state, life cycle, and communication mechanisms between different
sub-systems, and also identify the external interface.

Identify various usage scenarios.

1.2 Objective of HLD

1. To provide an overview of the entire system.
2. To provide a module-wise breakup of the entire system.
3. To provide introduction and high level working of every module involved.

1.3 Scope of HLD

This HLD covers all areas of system.

1.4 Acronyms and Definitions

This sub-section includes the definitions of all acronyms required to interpret the HLD properly.
Sr.

Acronyms

No.

Definitions

1.
2.

RADCONTROLS

TELERIK CONTROL SUITE USED FOR

3.

PROPERTY

PROPERTY MEANS THE PHYSICAL HOTEL.

4.

CLIENT

5.

COMPANY

CLIENT REFERS TO USER WHO PURCHASES THIS

SYSTEM
COMPANY REFERS TO PROPERTY WHICH IS A
HOTEL. ACCOUNTING SYSTEM WORKS AT A
PROPERTY LEVEL.

1.5 Reference
This sub-section provides a complete list of all documents referenced elsewhere in the HLD with
the details of the sources from which the references can be obtained.

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 5 of 34

<<Client Name>>
<<SystemName>>
List of reference document
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
m.
n.

System Architecture
System Features
Splendid CRM Architecture
System Database Design Document
Splendid CRM Database Design Document
Microsoft Exchange white paper
System Exchange Presentation
System Back Office Discussion
System Architecture Discussion
System Architecture Session 2
System Reporting Discussion
Time and Attendance Evaluation
SQL Reporting Service
MICR Check Printing

System Overview

2.1 System Overview

System is accounting system build for hospitality industry to cater Accounting and Sales CRM for
small and midsize property.

System is web enabled hosting solution for hospitality industry.

System includes Accounting, Sales CRM, Hotel Operations, Payroll and MIS Reports.
System will have Back Office to manage clients, clients properties, services and clients
users.
System is business to consumer B2C product.
System will sell the product in the form of modules, user licenses by roles.
System will be Rich Internet based Application running on the client browser. This includes
Web 2.0 and Ajax.
System Clients will buy license for one or more property (hotel). Each Property will run as an
independent company to perform Accounting, Sales CRM, Hotel Operations and Payroll
modules.
To maintain System application we need to build the Back Office module which holds
information about the System client and their multiple properties and users. This back office
is used by the System Back Office User to provide support to the System Clients.
System is segment in two sections
1. System Client
2. System Back Office
a. System Admin

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 6 of 34

<<Client Name>>
<<SystemName>>
b. System Back Office Sales Agent
SYSTEM CLIENT
This includes the following list of modules
System Client Admin
Hotel Operation
o Sales CRM
o NA function
o GM Function
Time and Attendance
Initiate Payables
Work flow
Accounting
o GL, AR, AP etc.
o Payroll
MIS Reporting

SYSTEM BACK OFFICE

This includes
System Back Office Admin
o Masters Management
o Agent Management
System Back Office Sales and Customer
Service
o Client Management
o Property Management
o License Management
System Back Office Operations
o Accounting

Design Considerations
This section refers to the decision made for building System. The supporting document to derive
the decision would be available either as a part of the appendix or as a part of the reference
section

3.1 Technology Consideration

Client Browser requirement is IE 6.0 and above.

Application must be hosted on IIS and should run in Windows Environment.
One or more Activex controls will be used in project. So while running on the client side
user is required to activate and allow running the activex controls.
Minimum Resolution required is 1024x768
We need to come up with emulator which runs on the client browser and does the require
client side setting to run our browser base application

3.2 Identity Management

User Identity : For user identity below listed parameters will be accepted through browser
user interface
a.
User Name: <name>
b.
Email: <<email>>
c.
Password: Alphanumeric (6 digit minimum)
d.
CAPTCHA: Graphic Image

System is a single sign on application to run Accounting, Sales CRM, Payroll, Hotel
Operations and MIS Reports based on user role and permission

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 7 of 34

<<Client Name>>
<<SystemName>>

When user is created in System, system should send invitation mail to user at a given
alternative email id.

Created user will have account in active directory and email will be created System
domain in MS Exchange.

We need additional function for check user availability (on the user screen)

User is authenticated against the back office database and then based on the location of
the database it gets relocated to that place.

User when logged in success full will have

a. Associated property(s) (if the user created at property level)
b. Associated client
c. Associated connection string which is stored in back office database
d. User role
e. User Authorization for folders, exchange user groups
f. User Permissions

User is locked means (user made an attempt for three times and could not log into
system). Supervisor will go and unlock the user.

All the places where the password is taken as an input we need to ask the CAPTCHA
image. For example when general manager is going to print payroll checks.

When the user is disabled we need the ability to transfer their mails to other users
account. This would be achieving through the request placed by supervisor user who has
the access. Either it would be a manual process or we shall run some windows service to
transfer info.

Asp.net forms authentication is used for System architecture. IAS does not have any strong
password policy and it uses plain text to store the password in the database table. We shall be
using 3DES encryption logic for password.
Authentication
method
ASP.NET forms

QMS Ver. No: 1.0

Description

Examples

Identity management systems that are not based on

Windows by integrating with the ASP.NET forms
authentication system. ASP.NET authentication enables
to work with identity management systems that implement
the MembershipProvider interface. You do not need to
rewrite the security administration pages or manage
shadow Active Directory, directory service accounts.

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Lightweight
Directory Access
Protocol (LDAP)
SQL database or
other database
Other ASP.NETbased
forms

Page 8 of 34

<<Client Name>>
<<SystemName>>

Authentication
method

Description

Examples
authentication
solutions

3.3 Design Consideration for Development

System Architecture will be defined taking IAS architecture as a reference. Every module in the
System should follow System architecture for building each component of the application.

All the namespaces used in IAS will be changed in System architecture.

For example: IAS Namespace refers to Enterprise as a root name space which will be changed
to SystemEnterprise

Naming convention: As per our discussion we will keep the same naming convention that 3
party tool is using i.e. IAS.

Steps to Upgrade IAS to System will be manual Process which will be defined in the detail
design document when starting the development activity

Steps to Upgrade SplendidCRM to System will be manual Process which will be defined in the
detail design document when starting the development activity

Database: In System we will have separate database for each client and that client can have
multiple property whose data will be stored in the same database.
a For e.g:
i. Client 1 DB [Physical database]
i. Property 1
ii. Property 2
ii. Client 2 DB
i. Property 1
ii. ..
iii.
b Some of the benefits listed below for having separate database for each client are as
follows:
i. Easy to implement
ii. Meta data identifies database instance for each tenant
iii. Number of tenants per database server is low
iv. Able to monetize the data extension/isolation feature
v. Scalable
vi. Performance is better
vii. Availability for the application will be 99.99 because unless the application
database fails.

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

rd

Page 9 of 34

<<Client Name>>
<<SystemName>>
viii. Database performance improves as the number user hitting a database is low
ix. Offisite database synch can be achieved easily

Physical Database Name for each client requires some pattern which will be defined in the back
office detail document at the time of development.

Any changes made in the System back office for the client data will require notification to the
client through email.

Windows Service will be created for making many of the background services. This process will
run for the client which is for all the properties rather than running service for each property

Some of the background process will be scheduled as a sql server job will run for each property

Supporting reports such as W-4, W-2, 1099 needs to be generated through system, so
somebody can manually write the data into actual form.

Further we will be using adobe form template then we will use other way to implement to display
form with template.

Non user access to System can be done through:

rd

rd

i.

Acro Print / any 3 party tool which records timesheet: In this scenario data from 3 party
tool will be pushed to System indirectly and required timesheet data can be captured.

ii.

Web Access: We can ask the same User Identity as stated in point 3 for access.

3.4 Single-Tenant Database vs Multi-Tenant Database

Decision taken in the favor Multi-Tenant Database

Each client will have their own physical database.
1: Single Tenant

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 10 of 34

<<Client Name>>
<<SystemName>>

2: Multiple Tenants

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 11 of 34

<<Client Name>>
<<SystemName>>

3.5 System IPR Decision Consideration

The long term future of the application is to produce some white label product which can be
available for the larger hospitality operator such as Hilton or Marriot.
The IPR valuation depends on the own application vs license application such as Sharepoint
server portal, which does not add valuation for white label products so it was not included in
the product development.
Sharepoint functionality objectives are still taken into account to achieve through
development.
Functionality
Email
Task
Calendar
Document Mgmt.

Explanation
Email function is taken care using Exchange 2007.
Calendar is taken care of exchange 2007
Calendar is taken care of exchange 2007
Document management when evaluated from the SRS and it found that
documents are attached to a given process and there are hardly any
documents
which
are
generic
in
nature.
These documents are process centric for example: Night auditor uploads
the document for a given specified date while closing the day of business.
Sales Contract Document is to be attached to the given opportunity or lead
and it is dynamically generated from the data

Work flow
Messaging

Product has certain part to have work flow that will be achieved through
windows work flow foundation
Messaging is done at client level and not across the client. Each client who
owns one or more property exchange messaging which will be taken care
in the application itself under Corporate

3.6 Rich User Interface Architecture

To achieve rich user interface which will be good, crisp graphics and looks, also should be a
ajaxified.
User look should be similar to office 2007.
Proof of concept is developed onsite in front of client and is being approved.

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 12 of 34

<<Client Name>>
<<SystemName>>

Telerik control have been selected for creating rich user interface which will comply web 2.0
standards
o To visit the link www.telerik.com

Telerik Control suite comes with rich 18 controls

We have taken Telerik controls Q1 2007 for the base development.

In future if there are new releases from the telerik and if required to integrate then we need to
upgrade the application with new release from telerik controls.

Dashboard element is associated with defined roles

User Presentation Needs to be customized based on different verticals

Illustration purpose
o Hotel Operations
Sales CRM
GM
o Travel Verticals
Sales CRM
The application user interface will be different and their way of function would be different and
also the web section in the dashboard those would differ based on the verticals selected.

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 13 of 34

<<Client Name>>
<<SystemName>>

3.7 Design Consideration of Existing Application (IAS and Splendid CRM)

IAS is taken as based for architecture and Quick books are taken as a reference for User
Interface and Functionality. IAS database, tables, procedures and middleware Web Service will
be taken in the development where as the user interface is going to redevelop and 80-85%
functionality will be based on quick book.

From the current IAS application we would be considering database and middleware
component. Limitation which has been discussed and will be address in the application
development

Current IAS does the data saving directly from the dataset into the datatables, and not using the
stored procedure.

For example: If we are designing the new Invoice screen it will include customer, invoice details,
bank details in one single screen while saving this records more than one table gets affected.
This will be done through using the stored procedures and these stored procedures will have
the business rule validation.

Front end component will be redeveloped to make the user experience rich and novice user can
use the system at ease. For example when the user going to create an invoice in the
accounting module, it will show the user something similar to paper invoice.

There shall be new web service methods to be added in the middleware to accomplish the new
user look and feel to achieve the new System architecture.

Splendid CRM Module is selected as a base CRM Module due to its functionality which has
been near to our requirement SRS.

Exchange Synch with CRM Database for each property should be stored different.

Contacts Synch is tied with User Roles

IAS Application and CRM Application will be merged into System architecture. System
Architecture guideline will define the merger process.

Splendid CRM database tables and procedures will be merged in to IAS database and the
middleware web services need to be developed and it should follow the same pattern as IAS
web services.

3.8 Design Consideration for the future provision

Web services developed as a part of the System will also be exposed for the interaction with
external entity

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 14 of 34

<<Client Name>>
<<SystemName>>

Interaction with external entity will happen only through the web services which has the
additional parameter as the login token

Any future enhancement should follow the System architecture guideline and needs to be
validated before implementing the changes

3.9 Design should consider for partial offline model

System Offline Model is a subset of the enterprise System application. System Offline is a web
enabled application running at a client machine with the local database and local IIS.

Offline application used when System main application is not reach.

System offline model would have few functions from Accounting and Payroll.

System offline database will have synch data from the central server.

When the data is changed from System offline then it will synch with central server.

Synch interval would be setting on the client side and this admin can change.

Offline model will have specific function such as payroll printing or processing at offline.

New user will not be created in case of offline model.

User will be validated from the local database against the central back office database.

User logging in the offline would not have email, connectivity.

Client side database would be SQL server express for storing the particular property
information.

Any change comes into System main application during the enhancement the changes are to
replace in the offline model.

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 15 of 34

<<Client Name>>
<<SystemName>>

3.10 Design Consideration of Application Performance and Scalability framework

The above diagram describes the performance and scalability frame on which we will be evaluating
the effectiveness of application performance.
The details about the each parameter will be taken in the detail design document when building the
application framework.

3.11 Assumptions, Dependencies, and Open Issues

3.11.1 Assumption

System Architecture will be build taking the IAS major release and tomorrow if the architecture
of the IAS is changed in the future release still System Architecture would not be changed
For example if the IAS comes up with the change in architecture in 2008 release then we will
not change the System architecture, but will provide mechanism to integrate the functionality

Client Side Deployment for the staging and production will be done from Cybage team.

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 16 of 34

<<Client Name>>
<<SystemName>>
3.11.2 Dependencies

Each new change coming in the future release would be aligned and would be merged into
System architecture as per the development guide line

Import and export data with other entity such as time and attendance or payroll integration.
These dependencies will be evaluated and will develop the bridges as required.

Acroprint Printer is a dependency item. If it stops entering then time will not be able to capture

3.12 General Constraints

During the development if there is a new release from the IAS or Splendid CRM with new
functionality then those will be carried out manually with the document and with approval from
client

During the development while storing the data in the CRM and storing the data in Accounting
would have different field names for the same functions which needs attention

System Development depends on Exchange which due to changes in configuration or due to

lack of service packs will not give the result as desired

Client Side environment is exclusive client responsibility so changes made in the client
environment will have some side effect which seems to be constraint

Client browser if not correctly set then System application will fail to run.

Client browser if not allowed to install active will fails to run the application especially in some
part of the application.

Some of the constraint will come for the check printing for which the printer setup requires
special attention which would require combine testing and documentation from cybage as well
as Client.

Generally popup will be avoided in the development but if there seems no alternative to achieve
the functionality then we may add the popup screen

While interacting with the exchange synchronizing the data field size might differ, this might
truncate the data.
http://msdn2.microsoft.com/en-us/library/bb508823.aspx

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 17 of 34

<<Client Name>>
<<SystemName>>

Some of the interop dependency might arise due to use of some of the base windows dll in the
exchange communication. This fixes need to be done as and when it arises

SQL 2005 will be upgraded to SQL 2008 only after stable release.

Any Error raise due to Service packs or any of the updates from Microsoft will not be in the
purview of Cybage. Cybage will find the fix and resolve them to the capacity of the knowledge of
the problem

Hardware configuration is not decided as of now. This decision will be taken once the
application moves to alpha version and would be nearing to beta version.

End user environment will be decided only after the development stage reaches the alpha
version but still some of the base line end-user environment are documented in the design
consideration

Verification and validation requirement needs to approve from the System for accounting
module.

3.13 Goals and Guidelines

System accounting will be developed along the guideline of quickbooks

System CRM would be developed along the guideline of splendidCRM

System Look and feel will be on the line of Office2007.

Organization of System

Hotel Application Architecture with Roles

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 18 of 34

<<Client Name>>
<<SystemName>>

Corporate Office
CEO

CFO/COO

CPA

Investors

Internet

Partners

Bankers

Hotel / Property
Hotel Back Office

Front Desk

Sales Manager

Accountant

General Manager

Book Keeper

Night Auditor

Architecture

The purpose of this section is to derive the initial architecture modeling which helps us achieving the
below objective.
1. Improved productivity. You can think through some of the critical technical issues facing
your project and potentially avoid going down fruitless technical paths.
2. Reduced technical risk. Your team gains the advantage of having a guiding vision without
the disadvantage of having to overbuild your system just because youve modeled it doesnt
mean you have to build it.
3. Reduced development time. Initial architecture modeling enables you to make better cost
and time estimates for your project, two pieces of information which management will want.

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 19 of 34

<<Client Name>>
<<SystemName>>
4. Improved communication. Having a high-level architecture model helps you to
communicate what you think youre going to build and how you think that youll build it, two
more critical pieces of information desired by management.

5.1 System Architecture

This section provides a high level overview of how the functionalities and features of the system
were divided and then assigned to sub-systems or components.
Below diagram displays the physical architecture required to build the system when it goes live.
Based on the resource availability and client confirmation we may go for similar infrastructure for
the staging site.
This is the based proposed representation of the application to be hosted. Actual setup at the
client will be different and that can be available as per the network diagram provided by the
client.

Following are the objectives achieved with the above diagram.

a. Every user will log into the system from the same site.

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 20 of 34

<<Client Name>>
<<SystemName>>
b. Back Office User and Sales Agent will also use the Site to login and perform
SYSTEMLIV back office operations
c. Every user in the System will have one associated active directory account
associated email address.
d. Exchange 2007 will be used for all sort of communication. Click here to read more
details Exchange 2007
5.1.1

Client Supplied Infrastructure

As per the diagram below, with the trusted segment there will be one additional box for the
application web server which runs System application.
In the internal network database would reside and will allow database access.
Big IP plays roles for load balancing and load sharing
Network infrastructure is total taken care by client and we do not need to make any changes.
We can recommend if we need some amendments.

Deployment document and setting will be made with keeping the existing client infrastructure
design

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 21 of 34

<<Client Name>>
<<SystemName>>

5.1.2

Any changes in the design would be notified from the client and we shall be making changes
in the deployment document.
System Site Architecture

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 22 of 34

<<Client Name>>
<<SystemName>>
System Site Architecture represent of how the different type of user is going to interact with System
Site and perform different activities
There are three groups of people involved who shall access the site
Type of User
Back Office Admin
Back Office Sales Agent
Back Office Customer Support
System Client (Owner)
System Client (GM, Sales Mgr, CPA,
Financial Controller, Book keeper)

Login url
<sitename>/Admin
<sitename>/Agent
<sitename>/Agent
<sitename>/client
<sitename>/client

Every User Who logs into the system will have see dashboard based on the role the user plays.
5.1.3

High Level Technical Architecture

System will be built on the multi-tenant SaaS model where the each client database would be
different database and would be connected based on the user and would be dynamic. The detail
technical details are as follows

Please refer to appendix for detail information

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 23 of 34

<<Client Name>>
<<SystemName>>
5.1.4

System Logical Architecture

Below is the System logical architecture which displays what the different projects are going to be
there to develop the complete solution and deploy on the site. This gives you higher level idea of how
the System site is going to be developed and also the different sections going to be in the
development process

5.1.4.1 System Development Project Setup

Developer Notes:
Based on the site architecture the project development structure will be as follows

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 24 of 34

<<Client Name>>
<<SystemName>>

System Solution
System Accounting
System CRM
System WebServices
System Accounting Webservice
System CRM Webservice
System Hotel Operation Webservice
System Back Office Webservice
System Authentication Webservice
System Payroll Webservice
System Hotel Operation
System Payroll
System BackOffice
System Reporting
System Document (this web site will take care of all the document being uploaded across all
the document)
System Plugin for Exchange for exchange connectivity
Databases
Back Office Database (one for SYSTEM which holds all the System clients)
System Databases
Accounts (tables, views, triggers, procedures)
CRM (tables, views, triggers, procedures)
Payroll (included in Accounts)
Hotel Operation (tables, views, triggers, procedures)
The above solution structure helps us achieve the below goals
Development will be independent and each individual can be assigned a sub section in the
whole solution
For integrating purpose and scalability this is more flexible
Document will be stored on the virtual path rather than the physical path this allows
independence of physical location of the document storage.
5.1.4.2

Technologies Identified

The list of the technologies used in the System Project is as follows

Functions
Web Pages
Language
Development IDE
Database
.net framework

QMS Ver. No: 1.0

Tools / Technologies
ASP.NET
VB.NET
Visual Studio 2005
SQL 2005
.NET 3.0

Confidential

Release
DD/MM/YYYY

Remarks

Dt:

Doc. Template Ver.

No. 1.1

Page 25 of 34

<<Client Name>>
<<SystemName>>
Version Control
Diagram
Documentation
Third party control
Unified Messaging
Reporting Tool
Bug Tracking System
Web Server
Scripting Language
Style Sheet
Add. Tech
Xilga tools
Analytics
IP Blocking

Unit Testing
Publishing
Code Documenting

5.1.4.2.1

VSS
Visio
MS office
Telerik Controls
Exchange 2007
Logixml
TTPro
IIS 6.0 with Windows 2003
Javascript / Vbscript
CSS
Xml based protocol exchange
For FAQs, Email
http://www.google.com/analytics/
We will use ip blocking database supplied
from client and also the interface need to
be created to configure from back office
as well as System client admin
NUnit
Visual Studio 2005
Visual Studio 2005

Same as eTravelStores

Exchange 2007

Applications that use Microsoft Exchange Server 2007 can access configuration settings and data by
using many different programming technologies. The topics in this section describe how to apply
these different technologies in Exchange 2007 collaborative applications.
Exchange Web Service Architecture for Adding Contacts, Task, Email and Calendar into exchange
from System System.

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 26 of 34

<<Client Name>>
<<SystemName>>

The following table lists the programming technologies that you can use to access Exchange 2007
settings and data.

Programming Technology Description

Microsoft ActiveX
Objects (ADO)

Data Applications use ADO to access data in the Exchange store by using
familiar database programming techniques.

Backup and Restore

The Exchange Storage Engine (ESE) manages the storage groups and
databases that Exchange 2007 uses. To support better performance
and better integration with failure recovery systems, the ESE includes
an API for backup and restore.

Collaboration Data Objects The CDO group of Component Object Model (COM) objects is the
(CDO)
primary way that applications access and control configuration settings,
users, messages, and other information in Exchange 2007.

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 27 of 34

<<Client Name>>
<<SystemName>>

Exchange
OLE
(ExOLEDB) provider

DB Applications use the ExOLEDB provider on the local server to access

the items in the Exchange store.

Lightweight
Directory Exchange 2007 supports the programmatic access of data at is stored
Access Protocol (LDAP)
in Active Directory by using the Internet standard LDAP.
MAPI

Exchange 2007 supports e-mail and collaboration clients that use

MAPI. MAPI uses remote procedure call (RPC) networking for client-toserver connections.

Microsoft.Exchange.Data
Managed APIs

The Microsoft.Exchange.Data namespace provides a wide variety of

types that facilitate tasks such as reading and writing Multipurpose
Internet Mail Extensions (MIME) data, converting message bodies and
other text from one encoding to another, reading and writing Transport
Neutral Encapsulation Format (TNEF) data, reading and writing
calendars and appointments, converting message formats, and
extending the transport behavior of Exchange 2007.

Schema

The Exchange store holds both data items and properties that describe
the items. Designing and managing the Exchange store schema is a
significant part of creating an effective Exchange collaborative
application.

Search

The Exchange 2007 content indexing and search functions support fulltext and property search queries over information in the Exchange
store.

Store Events

Collaboration and workflow applications can receive automatic

notification when events occur in the Exchange store. You can register
code that will be executed when the triggering event occurs.

Volume
Shadow
Service (VSS)

Copy The Volume Shadow Copy Service feature in Windows Server 2003
can be used to create applications that back up and restore Exchange
2007. VSS provides an infrastructure that enables third-party storage
management programs, business programs, and hardware providers to
cooperate in creating and managing shadow copies. Solutions that are
based on this infrastructure can use the shadow copies to back up and
restore one or more Exchange 2007 databases.

Exchange Web Services

Applications that use Exchange Web Services can access data store
items. The applications can access these items locally or remotely by
using a SOAP version 1.1 or version 1.2 message.

WebDAV

Remote client applications can use the WebDAV protocol to access

items and property information in the Exchange store.

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 28 of 34

<<Client Name>>
<<SystemName>>

Flow Diagram
Each module in the System Solution itself is a project by itself which are termed as module. Flow
diagram of each module is available in the detail design document looking at the SRS and
reverse engineering existing application
System Module wise flow diagram displayed in each module
a. Hotel Operation
a. Sales CRM
b. Night Auditor
b. Accounts
a. Payroll
c. Back Office

Design Limitations

IAS accounting system and splendid CRM System needs to be backward compatible as to
support any future release and those need to be merged with existing system

Splendid CRM is developed for one company so the company identity needs to be
established in each table and also in each stored procedure

Splendid CRM is developed using two tier architecture with c-sharp as language which needs
to be fit in System architecture with vb.net as a base language

System Solution is based on already existing application bought from the market with source
code. There is likely hood of any bug or error which might cause some issue in current
System design.

Splendid CRM is developed in the two-tier architecture with database and asp.net pages. The
application is built using c-sharp where as the development platform selected for the project
is vb.net as a language

Database architecture selected for the project is multi-tenant instead of single-tenant. This
does add additional operational effort.

System architecture is hybrid solution which is mix of one or more existing solution so there is
a lot more dependency involved while migrating and creating System solution and changing
the way it is being coded

User interface should look like office 2007 and to match exactly like office 2007 might be a
challenge. Practically we can achieve the office 2007 like functionality to the extent of 80%.

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 29 of 34

<<Client Name>>
<<SystemName>>

Splendid CRM is developed in c-sharp as language and it is built using user control
architecture.

Appendix

8.1 Blue Whale CRM

a. Blue Whale CRM
We are not going to Use Blue Whale CRM as a base CRM application. For some of the
functionality which refers blue whale we would be taking as defined in CRM Section of SRS.

8.2 Evaluation of Sharepoint Portal Server

Currently System is not going to use Sharepoint 2007 in their development

Client has listed down all the activities which they think would be done by SharePoint?
Client has idea that using SharePoint will make the application rich in terms of user
interface and also leverage on displaying personalization

Sharepoint is not a preferred choice is because we are not utilizing the full potential of the
application.
SharePoint will be bottle neck while creating our IPR to go to market with white label
SharePoint Licensing Issue does not provide the advantage for System to built
application based on sharepoint

8.3 Acroprint Evaluation for Time and Attendance

b. Integrating Acroprint Biometric Time and Attendance Application
Problem
Where does the employee information be
entered?

Acroprint outputs time and attendance file

which can be sent to payroll module and then
gets processing
Acroprint requires some manual interaction
where ever it is installed
Architecture to communicate for acroprint data
with System.

QMS Ver. No: 1.0

Confidential

Answer
a. First enter into System and then export to file
b. Import file to acroprint application and the scan
finger print info and setup
Or vice versa.
c.

d.
e.

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 30 of 34

<<Client Name>>
<<SystemName>>

8.4 High Level Design Document and their explanation for each component
The process services expose interfaces that smart clients and/or the Web presentation tier can
invoke, and kick off a synchronous workflow or long-running transaction that will invoke other
business services, which interact with the respective data stores in order to read and write business
data.
Security services are responsible for controlling access to end-user and back-end software services.
The most significant difference is the addition of metadata services, which are responsible for
managing application configuration for individual tenants.
Services and smart clients interact with the metadata services in order to retrieve information that
describes configurations and extensions that are specific to each tenant
We have not included smart client enabled application in the current scope of the development. The
design is made to address them in the future needs
8.4.1

Metadata Services

The metadata service provides customers with the primary means of customizing and configuring the
application to meet their needs. Typically, customers can make configuration changes in four broad
areas:

Workflow and business rulesTo be of use to a wide range of potential customers, a

business-critical application has to be able to accommodate differences in workflow. For
example, one customer of an invoice tracking application may require each invoice to be
approved by a manager; a second customer may require each invoice to be approved by
two managers in sequence; a third may require two managers to approve each invoice, but
allow them to work in parallel. When appropriate, customers should be able to configure the
way in which the application's workflow aligns with their business processes.

Extensions to the data modelFor many data-driven applications, one size definitely
doesn't fit all. Even with relatively simple, task-specific applications, customers may chafe
under the restrictions imposed by a static, unchanging set of data fields and tables. An
extensible data model gives customers the freedom to make an application work their way,
instead of forcing them to work its way.

Access controlTypically, each customer is responsible for creating individual accounts

for end users, and for determining which resources and functions each user should be
allowed to access. Access rights and restrictions for each user are tracked by using security
policies, which should be configurable by each tenant.

To provide customers with flexibility in configuring the software as necessary, these options are
organized into hierarchical configuration units known as scopes, each of which contains options for
making changes in each of the four areas listed above. Every customer has a top-level scope that it
can configure as needed, and the customer may establish one or more scopes underneath the top

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 31 of 34

<<Client Name>>
<<SystemName>>
level in an arbitrary hierarchy. A relationship strategy determines how and whether child nodes inherit
and override configuration settings from parent nodes.
For example, a typical customer that purchases enterprise-wide access to your application may have
several business units with distinct needs, all of which must follow certain company-wide standards,
but also must be able to configure some aspects of the application individually. Within each business
unit as well, there may be organizational groups that have their own special configuration needs. For
each of these identified organizational units, the customer can establish a scope that gives the group
access to the configuration options that it may set or change.
Ideally, customers should be able to configure the application through a wizard, or through simple,
intuitive screens that present all available options without causing information overload and that
clearly distinguish between options that can and cannot be changed within a given scope.

Approach

Security Patterns

Separate
Databases

Trusted Database

Extensibility
Patterns
Custom Columns

Connections

Scalability Patterns
Single Tenant
Scaleout

Secure Database Tables

Tenant Data Encryption
Shared
Database,
Separate
Schemas

Trusted Database

Custom Columns

Connections

Tenant-Based
Horizontal
Partitioning

Secure Database Tables

Tenant Data Encryption

Trusted Database
Shared
Database,
Connections
Shared Schema
Tenant View Filter

Preallocated

Tenant-Based

Fields

Horizontal

Name-Value

Partitioning

Tenant Data Encryption

Pairs

Comparision of the time and cost for application development using Shared Approach vs Isolated
Approach

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 32 of 34

<<Client Name>>
<<SystemName>>

Applications optimized for a shared approach tend to require a larger development effort than
applications designed using a more isolated approach (because of the relative complexity of
developing a shared architecture), resulting in higher initial costs. Because they can support more
tenants per server, however, their ongoing operational costs tend to be lower.
If you need to bring your application to market more quickly than a large-scale development effort
would allow, you may have to consider a more isolated approach.
Custom fields and Data Definition
Meta-data / data dictionary required
3 general approach
o Separate database for each tenant
o Shared database, a canned set of extended fields
o Shared Database, any number of extended fields
Trade off between each of the approach
Dedicated Tenant Database
1. Approach:
i. Separate database for each tenant
ii. Database maintains data dictionary
2. Advantages:
i. Easy to implement
ii. Meta data identifies database instance for each tenant
3. Tradeoff:
i. Number of tenants per database server is low
ii. Infrastructure cost of providing service rise quickly
4. When to use:
i. When tenant has data isolation requirements
ii. Able to monetize the data extension/isolation feature

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 33 of 34

<<Client Name>>
<<SystemName>>
Shared Database, fixed set of extensions
1. Approach:
i. All tenants data in one database.
ii. Pre-defined set of custom fields
2. Advantages:
i. Easy to implement
ii. Maximize number of tenants per database server
3. Tradeoff:
i. Tendency to results in sparse table
ii. When to use:
iii. When data co-mingling is OK
iv. Easy to anticipate pre-defined custom fields
Same database, variable custom extensions
1. Approach
a. All tenants in one database
b. Variable number of custom fields
c. Name-value pair in separate tables
2. Advantage
a. Unlimited number/option for custom fields
3. Tradeoff
a. Increase index/search/query/update complexity
4. When to use
a. OK to co-mingle tenant data
b. Custom fields are high value features
c. Difficult to predict custom fields

QMS Ver. No: 1.0

Confidential

Release
DD/MM/YYYY

Dt:

Doc. Template Ver.

No. 1.1

Page 34 of 34