LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
Project Vision“The vision of this project is to provide abetter customer service through anintegrated enterprise application systemand enhance the efficiency of engineeringsupport 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 RequirementsFunctional 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 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
Technical decisionsEngineer 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
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•Client-Server Architecture Presentation Layer Sugar Web browser Control Layer Jira Document Repository Engineering Support support portal portal backend backend
Other considered Approaches DrawbacksFile 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 andSubsyst 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
• 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