The document describes a proposed architecture for an engineering support system to better integrate existing systems and provide a unified portal. The key goals are to improve customer service, enhance engineering team efficiency, and integrate systems like Jira, SugarCRM, and others. The proposed architecture uses a centralized WSO2 identity server, unified portal, and WSO2 ESB for loose coupling. This allows new systems to easily integrate, a unified data view, high availability, and other benefits.

1. Engineering Support
System
Group 12

2. 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.”

3. 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.

4. 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.

5. Non Functional Requirements
• Security
• Availability
• Unified view of data
• Accuracy
• Availability

6. Proposed Architecture
Engineer Client
Multiple Access Channels
(eg. Web, Mobile, Email, etc.)
Unified portal
CS App ES App
WSO2 ESB
WSO2 WSO2
SugarCR
Jira governance identity
M
registry server

7. Technical decisions
Engineer Client
Multiple Access Channels
(eg. Web, Mobile, Email, etc.)
Unified portal Device sensitive web
portal
CS App ES App
WSO2 ESB
WSO2 WSO2
SugarC
Jira governance identity WSO2 identity server
RM
registry server will be used as the
LDAP instance

8. Lead to Contract activity flow

9. Report Issue to Resolution

10. 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

11. 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)

12. 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

13. 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.

14. 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

15. 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

16. Other Considered Architectures
•Client-Server Architecture
Presentation Layer
Sugar
Web browser
Control Layer
Jira
Document Repository
Engineering
Support
support
portal
portal
backend
backend

17. Other considered Approaches
Drawbacks
File Transfer Pattern • A common file type has to be
agreed between different
subsystems
Portal Portal • Each subsystem must be
1 2 modified as it can convert own
data in to agreed file format and
to extract data from receiving
Controller
files.
• Adding new functionality in to
each subsystem is difficult and
Subsyst Subsys Subsys time consuming
em 1 tem 2 tem 3 • Transferring data using files is
less efficient.
• Controller has do complex tasks
to manage file transfers

18. • Remote Procedure Invocation Pattern
Middleware (Object Request Broker)
Subsystem 1 Drawbacks
• Applications has to be aware of
Portal A other applications
• Integrating new applications or
Subsystem 2 altering existing applications is
difficult.
Portal • Systems like sugar CRM does
B not support RPC
Subsystem 3