EasySOA: Enterprise Open Information System (Business Case)

Transcription

1 EasySOA: Enterprise Open Information System (Business Case) Version Public Deliverable, V1.0 Date December 31 st, 2012 Authors EasySOA partners: Inria / EasiFab, Bull, Nuxeo, Open Wide, Talend Contributors - Public deliverable, V1.0 December 31 st, / 8

2 Summary 1.Context Business context and requirements Enterprise Open Information System: specification of the architecture Functional point of view Business Architecture layer Information Architecture Layer Application Architecture Layer Technology Architecture Layer Operational (deployment) point of view...8 Public deliverable, V1.0 December 31 st, / 8

3 1. Context This document is produced on behalf of the EasySOA consortium, which collaborates at building the EasySOA Open Source platform, whose goals and results are shown at As shown in the Figure below, main goal of EasySOA is to add a light and agile layer around the traditional SOA middleware architecture. This current document describes the Business Requirements part of an exemplary Business Case about an Enterprise Open Information System (EOIS). This Business Case aims at being a support to the final demonstrator of the EasySOA platform capabilities. This Business Case is closely inspired from a real business project, led by Open Wide some time ago and whose achievement was imperfect, since it didn't perfectly meet the customer's needs and expectations. Among the different reasons of this relative underachievement, one was the incompleteness of the SOA approach and technologies deployed for this customer at this time. It is why this Business Case built from the feedback of this real business experience appears so exemplary for the EasySOA consortium to show the new SOA capabilities enabled by the EasySOA platform. This document addresses both the business context and requirements as defined and adapted to the EasySOA context, and the specification of the architecture of the part of the EOIS to be implemented with the EasySOA platform. Public deliverable, V1.0 December 31 st, / 8

4 2. Business context and requirements The business context in question here is that of a company (let's name this company NAHV, National Agency for Holiday Vouchers) which sells to salaried employees enterprise-sponsored holiday vouchers. NAHV uses its sales benefits to fulfill its social mission as a public service, by allowing underprivileged people to go on holidays. Two main and distinct departments collaborate to this mission (respectively DCV and DPS), each with its own IT department. DPS department works mainly with manual processes, paper documents and some Excel forms. DPS wants to provide its business teams with fully automated business solutions integrated within an enterprise open information system. DPS needs to operate a new information system with business applications, consistent with each other, and collaborating and consistent with the business applications and information operated by the DCV department. DPS needs to operate the following business systems: A web oriented system to support one of its social programs, whose name is APV. This system should be accessed by any social partner known from NAHV to deposit requests for holiday fundings, whose beneficiaries are underprivileged people sponsored by the social partners. Social partners are first registered by the DCV department, and this same department decides and actualizes some indicators useful for fundings as requested by each social partner A web oriented system to support another social program, whose name is BSV. This program is very similar to the APV program, and will not be considered in our business case The business case described here focuses on the DPS business requirements, and DPS point of view. The business case considers the collaboration between DPS and DCV, as two separate departments, in order to allow DPS to operate its new information system, including the APV business application. The business case considers particularly the interaction between two business processes respectively operated by DPS and DCV: the first one is the Request for a First Registration of a Social Partner (name given in the design and the implementation with the EasySOA platform will be known in French as Demande Création Précompte ). This business process is operated by DCV the second one is the Request for Holiday Funding by a social partner (name given in the design and the implementation will be known in French as Demande Projet Vacance ). This business process is operated by DPS note: in the context of the EasySOA project, the description and the modeling of these two business processes isn't known The two business processes interact each other and need coordination as follows. The First Registration of a social partner and the indicators ruling the Fundings (processed by DCV) is limited according to the type of organization of the social partner (Association, Social Centre, etc.) and constraints the opening of Request for Holiday Funding to the people helped by the given social partner (processed by DPS). Public deliverable, V1.0 December 31 st, / 8

5 This entails two particular business requirements: one is a functional requirement in terms of business activity monitoring of some DCV activities (related to the evolution of business indicators ruling the Fundings) so that it enables control by DPS another one is a non-functional requirement from an operational point of view (at runtime), or service level requirement, in terms of response time and availability of the operation of the business process operated by DCV, as requested by DPS and agreed with DCV To summarize, the business context and requirements as considered in our business case focus on: Business Process 1, Request for a First Registration of a Social Partner (in French Demande Création Précompte ), whose owner is DCV Business Process 2, Request for Holiday Funding (in French Demande Projet Vacance ), whose owner is DPS Coordination between the two Business Processes 1 and 2 Business Activity Monitoring related to some activities of the Business Process 1, requested by DPS and agreed with DCV Service Level Requirement by DPS and Agreement with DCV related to the operation of the Business Process 1 The next part of the document describes the specifications of the architecture of the NAHV EOIS implementing this business context and requirements. Public deliverable, V1.0 December 31 st, / 8

6 3. Enterprise Open Information System: specification of the architecture 3.1. Functional point of view The following figure shows the overall architecture, from a functional point of view, agreed both DCV and DPS to implement the Business Case, as described here above. Figure: NAHV EOIS overall architecture, functional point of view This overall architecture shows first main orientations as chosen and agreed both by DPS and DCV IT teams: SOA is the core of the architecture both for implementing the automated part of the business processes related to the Business Case (by an orchestration of services), and for the integration of the two parts of the EOIS, one operated by DCV (DCV IS) and the other one by DPS (DPS IS). Two orchestrations appear here, Orchestration_DCV operated in the DCV_IS, and Orchestration_DPS operated in the DPS_IS Public deliverable, V1.0 December 31 st, / 8

7 To operate the Business Process 1, and to operate the coordination with the Business Process 2, the CRM application currently operated in the DCV IS (based on Pivotal CRM software) is exposed by services Cré_Pré_Cpte and Contact_Client (encapsulating the management of rules and information related to Fundings) To ensure data consistency related to the Address information (needed for registration of contacts in the CRM, such as social partners), an external service is used ( checkaddress ) and provided by an external provider ( Uniserv ). This service is part of Orchestration_DCV A SLA (Service Level Agreement) is defined to enable the control of the service level of the operation of the Cré_Pré_Cpte service. This control will be processed using the EasySOA Service Monitoring system. The control of this SLA entails the definition of another service level, requested by DCV to Uniserv, as an external provider. This service level is defined as an OLA (Operational Level Agreement) agreed between DCV IT and Uniserv and is related to the operation of checkaddress service The BAM_Pré_Cpte is defined and will be implemented to enable the control of the BAM activity of Cré_Pré_Cpte, and this control will be processed using the EasySOA Service Monitoring system The other main elements (components) of the overall architecture as shown here above are summarized as follows Business Architecture layer Demande Création Précompte, inherited from the Business Process 1, appears here as an event, or an automated business activity (or task), or a service, provided by DCV, and consumed by NAHV Sales in the same way, Demande Projet Vacance inherited from Business Process 2, service provided by DPS and consumed by Social Partner Information Architecture Layer Cré_Pré_Cpte is the service implementing or resolving a part of Demande Création Précompte, and used for integration purpose between DCV_IS and DPS_IS, provided by DCV IS and invoked by any user with NAHV Sales role, whose service level is defined by SLA Cré_Pré_Cpte Contact_Client is the service implementing rules and information for Fundings BAM_Pré_Cpte is the service monitoring the activity of Contact_Client and will be the data source for the EasySOA Service Monitoring for control of Cré_Pré_Cpte checkaddress is the service implementing the data consistency of Address information, provided by Uniserv and consumed by Cré_Pré_Cpte, whose service level is defined by OLA checkaddress Projet_Vacance is the service implementing or resolving a part of Demande Projet Vacance, provided by DPS IS and invoked by any user with Social Partner role Public deliverable, V1.0 December 31 st, / 8

8 TdrWebService, Information_APV are two other services implementing some rules and information useful for integration between DPS_IS and DCV_IS Note: content and functionality of those two services are nor quite defined nor used in the context of our Business Case Application Architecture Layer Orchestration_DCV is an application component implementing Cré_Pré_Cpte Orchestration_DPS is an application component implementing Projet_Vacance Pivotal CRM is a Web application component implementing the business and data logic of a part of Demande Création Précompte APV Web is a Web application component implementing the business and data logic of a part of Demande Projet Vacance Web_UI are application components implementing the presentation logic and user interface of a part of Demande Création Précompte and Demande Projet Vacance other application components implement the services, as defined here above Technology Architecture Layer TALEND ESB is a technology component used for realization of Orchestration_DCV and Orchestration_DPS TALEND SAM (Service Activity Monitoring) is a technology component used for the monitoring of TALEND ESB, and provides the EasySOA Service Monitoring with processing time data Embedded CXF is a Web Service technology component used for realization of all the services as described here above JAVA is a technology component used for coding most of the application components, as defined here above 3.2. Operational (deployment) point of view The NAHV EOIS, as illustrated by the final demonstrator of the EasySOA, is deployed to 3 distinct environments (virtual machines): one for DCV IS, embedding Pivotal CRM, TALEND ESB, TALEND SAM, Orchestration_DCV, Uniserv, and all DCV services one for DPS IS embedding APV Web, Embedded CXF, TALEND ESB, and all DPS services one for Service Monitoring and Registry, embedding JASMINE, NUXEO, Service Monitoring, OSGi Public deliverable, V1.0 December 31 st, / 8