B.I.T.S. Pilani, M. Tech.

Software Systems
SOFTWARE ARCHITECTURES (ZG653) – Assignment 1

Date: 27th February 2018 Group: GROUP 19

2018HT13201 2018HT13080 2018ht13359 2018ht13083

Karthikeyan Saketh Arun A Srinivas

Anbarasan Konakanchi

System Overview:
The system which is selected for our evaluation is the Customer Relationship Management
(CRM) and this system is selected for evaluation keeping in mind this can be widely used
irrespective of the domain and technology. The system is used widely as every business has
Customer base and this leads to managing the customer relationships, tracking the sales,
marketing the business, building the pipelines and delivering the required metrics and analytics
for the end users.

Purpose:
The purpose of the system depends on the rationale of the business and the domain by which the
revenue is streamlined. If we take a call center business the purpose of this system will be mainly
as below
• Increase the Customer Service Levels
• Improve efficiency of the calls received
• Manage the SLAs in rectifying the issues
• Cross sell products
• Helping sales team to follow through enquired customers
• Simplify marketing processes and provide clarity on target audience
• Increase the visibility to the management with reports and analytics

Key Requirements
The key requirements which drives the implementation of the system includes the following.
 • Cost effective system to drive the business
• Path towards digital transformation of the LOB
• Secured channels to streamline the revenue generation
• Having an omni channel environment for the revenue generation
• Reporting and analytical modeling as per the business requirements
• Integration with all business core systems.
• and many more…!

Architecturally significant requirements of the system can be described as:

1. Modularity and Interoperability

a. Customizable according to the needs of the enterprise.
b. Hassle-free integration with existing business applications.
c. Integrate data from various sources.

2. Security – Allow users to access only the data that they are authorized for.

3. Ad-hoc Query Generation – Generate and process ad-hoc queries on the data as per the
requirement.

4. Deployment – Allow both Cloud and on-premise solution deployment.

5. Process history of customer data and provide insights for enhancing customer
relationships.

Tactics Used to Achieve

The key Tactics used to achieve this system implementation is as follows:
1) Security – Microsoft® has built the security model of this system very effectively. The
model mainly provides three main features:
a. Users can access only that data, which is appropriate for their job, not to any other.
b. Different roles are introduced, and data access is given based on these roles.
c. Users will be able to share data with others without giving any ownership.

The types of Security in Dynamics CRM are:

a. Role based security: It provides specific sets of privileges to a user in Dynamics
CRM.
b. Record based security: It allows or restricts access to specific records in the CRM.
c. Field level security: It allows or restricts access to specific properties on an entity
type in Dynamics CRM.

Some of the default security roles available are:

a. System Administrator
b. System Customizer
c. CEO
d. Sales Manager
 e. Sales Person

Each role is essentially a combination of one or more of the following privileges: Create,
Read, Write, Delete, Append, Assign, and Share. Apart from these, there are 580 different
kinds of security roles available in the system!

2) Modularity and Interoperability:

a. Each component/entity in the system is abstracted in such a way that, even physical
properties like button text, colors, sizes, etc., can be customized according to the
client’s needs and business processes.
b. Dynamics CRM uses a plugin – based architecture to achieve modularity.
c. There are a whole lot of prebuilt plugins which can be used by the user out-of-the-
box.
d. Apart from these, users who also have some programming knowledge can create
their own plugins and use them along with the application.

3) Ad-hoc querying support is provided by using a Query processing layer in the

architecture. The different components of the query processor structure are as follows:
a. Query builder – this component builds SQL queries that are executed on the SQL
Server database, to find and retrieve data through the application.
b. Query Processor – This component is responsible for executing the queries in an
optimized way, using the Query plans.

Software Architecture Diagram

Front End Fire Wall + Load Balancer

Active Directory
Backend Systems
3

2 AD 4
ERP
Cluster Web Server
1 5

CRM DB SMS
SQL Cluster (Firewall)

Pay
SQL DB Node 1 SQL DB Node 2
Architectural Comments
The component is modularized keeping in mind loosely coupled architecture with extending the
Presentation layer, Business layer and Data layer separately. The architecture can be extended to
further enhance the abstraction with in the web application layer by loosely coupling Web and
application tiers and making it scalable.

Key Learnings / Lessons learned

Student 1:
Karthikeyan Anbarasan (2018HT13201)
Architecting a system which is Client Server model or a standalone modeled makes a vast
difference in modeling the component and layering it with the respective tiers. While architecting
the system the interfacing and modeling should be defined in such a way it follows Service
oriented methodology inorder to cater the reusability across the systems.

The difference in building the system from Scratch and reusing the existing system and building
the components in terms of plugins and extension are different as such in Dynamics CRM its
noticed that using the system has provided with lot of limitations in accessing the databases and
extending the funciotnality in the DB level or in the application stack.

As a best practice selecting the system for the business needed depends on the factors like time,
money, material etc and I believe this derives the stakeholders to take the decision on selecting
the product.

Student 2:
Saketh Konakanchi (2018HT13080)
Custom-built applications are client-specific and have a very narrow scope of requirements (in
comparison). Their architecture is designed to suit the needs of the enterprise. Only in a few cases,
the same architecture/design can be applied or used for another client.

But generic product applications are not specific to the needs of any client. Their
build/architecture must be as solid/generic in nature such that it can be used by any type/size of
company. The design must be more accommodating many more use-cases and should be
extendible or customizable enough for any type of client to start using it. It must be more secure,
should have high availability (if at all used by large clients) and should be more performant.
Student 3:
Arun A

Student 4:
Srinivas