Engineering Support System

Group 12

Project Vision

“The vision of this project is to provide a

better customer service through an

integrated enterprise application system

and enhance the efficiency of engineering

support teams.”

Project Goals

• integrate a set of existing and proposed systems in such a way that their collective functionality is directed towards achieving the above mentioned vision.

System’s Main Requirements Functional Requirements

• Recording the email conversations with the clients.

• Engineers and clients should be able to access SLAs.

• Clients should be able to inform an issue and request patches.

• System should be able to create client accounts automatically.

Non Functional Requirements

• Security

• Availability

• Unified view of data

• Accuracy

• Availability

Proposed Architecture

CS App

Multiple Access Channels

(eg. Web, Mobile, Email, etc.)

Unified portal

WSO2 ESB

WSO2

governance

registry

WSO2

identity

server

SugarCR

M Jira

ES App

Engineer Client

Technical decisions

CS App

Multiple Access Channels

(eg. Web, Mobile, Email, etc.)

Unified portal

WSO2 ESB

WSO2

governance

registry

WSO2

identity

server

SugarC

RM Jira

ES App

Engineer Client

Device sensitive web

portal

WSO2 identity server

will be used as the

LDAP instance

Lead to Contract activity flow

Report Issue to Resolution

Advantages of proposed architecture • New portals can be easily integrated to the existing system

• Central authentication server can be added for security

• No single point of failure

• Unified view of data through portal

• Less redundant data (Each system maintains data which are specific to that system)

• Low latency and no blocking operations

• High extendibility

• Technology independent subsystems (Each subsystem can be implemented using different technologies)

• Loosely coupled subsystems

• Authentication and authorization support at every level

Advantages of proposed architecture

• Complexity of Jira is hidden from customer throu CS portal.

• Engineers get a unified view of data form ES portal.

• Data is not replicated in ES or CS.(They are in the base systems : Jira, Sugar, Registry)

Quality Attributes

• Security

o Authorization/authentication based on a central LDAP

o Role based access control

• Performance

o Zero latency

o Streamline processes

o Minimum response time

• Availability

o 24/7 availability

• Maintainability

Assumptions Made • support accounts are not activated until a contract

with the client is signed.

• There is a common mechanism relate data of a user account distributed in different servers.(E.g. user ID is similar for an user in every server)

• Different subsystems used in this overall system support a web service interface. If not an adapter has to be developed.

Assumptions - Continued • All the authentication must happen through a

centralized LDAP server

• No monetary payments has to be considered as they have not mentioned.

• New system to manage patches is not needed. It can be done through JIRA.

• Users can directly interact with the existing subsystems as previously even in the new system

Ambiguities • User roles are not well defined (e.g. if a user is

logged as an engineer he will have the access to data of all the engineers)

• Disaster recovery and backups are not specified.

• Security requirements other than role based security is not specified

Other Considered Architectures W

eb b

row

ser

Pre

sen

tati

on

Lay

er

Co

ntr

ol L

ayer

Sugar

Jira

Support portal

backend

Document Repository

Engineering support portal

backend

•Client-Server Architecture

Other considered Approaches

Subsystem 1

Subsystem 2

Subsystem 3

Portal 1

Portal 2

Controller

File Transfer Pattern

Drawbacks

• A common file type has to be

agreed between different

subsystems

• Each subsystem must be

modified as it can convert own

data in to agreed file format and

to extract data from receiving

files.

• Adding new functionality in to

each subsystem is difficult and

time consuming

• Transferring data using files is

less efficient.

• Controller has do complex tasks

to manage file transfers

• Remote Procedure Invocation Pattern

Portal A

Portal B

Subsystem 1

Subsystem 2

Subsystem 3

Mid

dle

war

e (O

bje

ct R

equ

est

Bro

ker)

Drawbacks

• Applications has to be aware of

other applications

• Integrating new applications or

altering existing applications is

difficult.

• Systems like sugar CRM does

not support RPC