SITA PXM BU Overview IS

1

SOA Overview and Praxeme Insight for Business Users – copyright www.orchestranetworks.com Version - August 13th, 2007

Version – August 13th, 2007

Pierre Bonnet - Orchestra [email protected]

SOA overviewand Praxeme insightfor Business Users

(V2 reviewed by Oscar Chappel from ILOG Company, 2008-02-25)(V1 in English Language)

SOA stands for Service Oriented ArchitecturePraxeme is an enterprise method

2


Agenda

Why SOA ? The enterprise method IS urbanization and SOA BPM and SOA

Pre-modeling A method shared by users

and IT specialists Delivery phases

Encouraging agility

Batch and SOA Software package and SOA

How to evaluate quality of SOA?

Risks The financial value of SOA

3


Reference to Praxeme

Praxeme is a public method (free of charge) created by Dominique Vauquier and downloadable on Praxeme’s website: www.praxeme.org

Texts and figures that come from Praxeme’s guides are indicated by the creative common’s logo:

By Dominique Vauquier(www.praxeme.org)

4


Reference to SMABTP’s project

These slides use examples that come from SMABTP’s project regarding the overhauling of Information System and more precisely the Insurance Claims Management Systems

Many thanks to Jean-Michel Detavernier, Deputy CIO of SMABTP and Project Director for the overhauling of IS

SMABTP is an insurance company

5


Pierre Bonnet

Co-founder of Orchestra Networks company, independent software vendors in the landscape of Master Data Management. Pierre is responsible for Consulting Operations

IT expert and project management in the context of SMABTP’s project

Co-author of the Praxeme method since 2005

6


Why SOA ?

Around 2002, the SOA term (Service Oriented Architecture) is proposed by the Gartner Group, relying on some of their former analysis reports going back to 1996

7


How do we cope with?

End-of-life of existing systems Maintaining existing IS assets is tricky IT budgets are increasing: too many software layers Realizing new functions requires too much time

Loss of business knowledge through retirement and attrition of business expertise Business knowledge is mainly kept through existing applications It is a dangerous situation

Retirement of IT specialists These people have in most cases built existing systems What will happen after retirement of seniors IT specialists?

A break period is occurring…

8


In this contextWhat are objectives of SOA?

SOA will allow for a progressive and sustainable overhauling of functional and technical silos so as to design reusable services that will be called in various business processes

9


Functional and technical silos

Functional silo Functional silo

Customer

Functional silo Functional silo

Technical silo (MVS) Technical silo (AS400) Technical silo (Unix, Java)

Functional silo

Technical silo (Internet)

Contract

Claim

People

Customer

Contract

Financial

Product

Contract

Product

Claim

People

Permission Permission Permission Permission Permission

GUI GUI GUI GUI GUI

?? ?

• No end-to-end processes (no seamless processes)

• Multiple data keying

• Low data quality

• Heterogeneous GUI

• Permission management is not unified

• Openness to third parties is tricky

10


Functional silos

Order entry

Updating address

Selecting product code

Choosing quantity

Calculating discount

Customer care

Updating address

Score analysis

Sending mail

• Duplication of “updating address”

• Different GUI

• Maybe data duplication related to address management

Using Business Objects and SOA, urbanization is enhanced and redundant functions can be removed

Urbanization with silos generates redundant functions

This is a metaphor stands for logical organization of the IS – Kind of IT City Planning and Enterprise Architecture

11


Overhaul with SOA

Customer Order Product

Order entry

Updating address Selecting product codeChoosing quantity

Choosing discount

Customer care

Score analysis

Sending mail

ORGANIZATION STRATUM : organizational rules, rights management, integrity of business transaction, customization according to execution contexts, orchestration of services that are located in business stratum. These orchestrations implement processes and use-cases.

BUSINESS STRATUM : reusable services for any organization, Business Objects lifecycles, regulatory rules (core business rules)

Sem

anti

c as

pec

tP

rag

mat

ic a

spec

t

12


Overhaul with SOA

Master data and parameters

management system

MDM

Business Rules Management System

BRMS

System inter-working (ESB - Enterprise Service Bus)

Functional silos Technical services

- Printing- Supervision- Running- ../..

Third parties systems

IHM – Unified web portal

VARIANTS

VARIANTS

Customer Order Product

Order entry

Updating address Selecting product codeChoosing quantity

Choosing discount

Customer care

Score analysis

Sending mail

ORGANIZATION STRATUM : organizational rules, right management, integrity of business transaction, customization according to execution contexts, orchestration of services that are located in business stratum. These orchestrations implements processes and uses-cases.

BUSINESS STRATUM : reusable services for any organization, Business Objects life-cycles, regulatory rules (core business rules)

13


Variants of service

IT

Business

Without variants of service

With variants management

service service

Example : order entry with three variants

Retailer 1

Order entry

Retailer N../..

VARIANTE

Variants are declared according to execution contexts• Products• Processes• Right management• Rules• …

Not SOA!

14


What about SOA ?

Approach for overhauling IS in a progressive manner This is not a technical approach nor a method Computational language oriented service doesn’t exist

This a reference framework that gathers several decades of computational know-how Object-oriented approach UML notation Design by contract Process Re-engineering and workflow Urbanization of IS (enterprise architecture, IT City planning) Level of abstraction and separation of concerns: conceptual,

business, organizational, etc. Etc.

SOA encourages us to set up an enterprise method which will bridge the gap between business and IT, encouraging a better alignment of Business with IT

15


Levels of maturity

Cosmetic SOA Non intrusive to existing asset: services are exposed with

help from existing systems This is not a rewritting of systems yet This SOA is reliant on quality of existing systems This SOA allows for obtaining some limited quick wins

Overhaul SOA Re-structuring existing applications with help from services IT infrastructure can be fully used

Extended SOA Using solutions that enhance the agility of systems:

Business Rules Management System, Master Data Management, Business Process Management

16


The SOA maturity matrix

MDM : Master Data ManagementBPM : Business Process ManagementBRMS : Business Rules Management System

IS overhaul

• End-of-life of IS• Retirement of IT people• Loosing business knowledge

17


Benefits of SOA to Business Users

Reusing of services GUI components (see screenshot at the next page) Programmatic components – Data flow

Real time business intelligence Take decision more quicly

Opportunity to set up an enterprise method so as to Streamline costs Increase planning and delivery speed Align business with IT Manage risks of overhaul IS projects

18


Reusable activity

Reusable activity

Reusable activity

Reusable activity

Reusable activity

The whole screen: insurance claims management - Mash-up (composite application)

Business functions

Figures - SMABTP Project (overhaul in a context of insurance company)

19


Example of reusable services Programmatic service (without GUI)

Referential data access Products and services configuration, etc.

Batch (monthly basis)

Automatic customer

churn analysis and

automatic offers

configuration

New offer to retain customers

Call center(real time)

Customer wants to

cancel his contract

Lack of proposal!

SERVICE : Offers configuration

Batch (monthly basis)

Call center(real time)

Proposal to retain customers

Siloed approach SOA removes silos

20


Real time key indicators

Copyright Information Builder

Updating of the Dashboard in real time

21


The enterprise method

22


What are benefits in the enterprise method?

Must allow to define Products - Specify what the project must deliver Procedures or operational guidelines – Specify how each

designer and developer handles the fabrication of products Process – Specify the project life-cycle

Products are sometimes identified Procedures or operational guidelines are rarely describe In most cases the project life-cycle exists: UP, RUP,

ISO, TOGAF (dedicated to architecture governance), etc.

Towards the IS Topology


23


Praxeme’s topology By Dominique Vauquier(www.praxeme.org)

Pre

-mo

del

ing

S?mantiqueSemantic

PragmatiquePragmatic

G?ographiqueGeographic

Modeling of requirementsOwned by Business users

CORE BUSINESSBusiness Objects

Lifecycle of Business ObjectsInformation modeling

WITHOUT ORGANIZATIONAL CONCERNS

ORGANIZATIONOrganizational structure

Human resourcesBusiness processes

Uses-cases

NOT YET UML but ALREADY REUSE MINDSET!

24



Pre

-mo

del

ing

LogiqueLogicalS?mantiqueSemantic

PragmatiquePragmactic

G?ographiqueGeographic

SOA Logical Architecture (*)Owned by Business and IT People

(*) SOA is a style of logical architecture: neither technical architecture nor business architecture

25



Pre

-mo

del

ing



G?ographiqueGeographic Mat?rielHardware

TechniqueTechnical

LogicielSoftware

PhysiquePhysical

Owned by IT Specialists

26


Semantic Aspect

Core business Domains of business objects Information modeling Business objects lifecycles modeling


Product

Contract

Serviceprovided

- Five domains of business objects

- Overhaul perimeter:

- Cosmetic perimeter:

- Common Information Model

Reality

Account

Person, customer, expert, company, objects that are insured, address…

Insurance claims managementCustomer care…

27


Ex: Lifecycle of Business Objects

Ouvert en gestion

Déclaré

Annulé Périmé

Terminé

Décrit ouvert ré-ouvert

Terminé avec réglement

Terminé sans réglement

/purger()

[X ans]/périmer()^Sinistre périmé

Couverture évaluée/ré-ouvrir()^Sinistre ré-ouvert

Couverture fermée[Toutes couvertures fermées]/fermer()

[Au moins un règlement]

[aucun règlement]


/déclarer()

Couverture évaluée/ouvrir()

/annuler()^Sinistre annulé

/décrire()

/décrire()

[Contrat, dommage et famille décrits]/décrire()

/décrire()

State machine of “Claim” Business Object


28


Pragmatic Aspect

Modeling of organization Use case = micro-process by actor Process between several actors

Organization rules must be isolated from others Organization rules are implemented by software

packages that enhance agility BRMS - Business Rules Management System MDM - Master Data Management

29


Process and use case

Step Step Step

Step

Step

Actor 1, Tps1 Actor 2, Tps2 Actor 2, Tps3 Actor 5, Tps5

Actor 4, Tps3

Activity Activity Activity

Activity

Activity

Process

Micro-process is also named use case

Actor 1, Tps1

30


Design approach for processes

The good approach Firstly identify the main business object that composes

the process Secondly reuse its life-cycle (already design in the

semantic aspect) to automatically obtain the first version of the process: this is the conceptual process!

With help from this conceptual process you may model the future organizational processes. The level of alignment can be seen through differences between the conceptual process (reference process) and new processes

Do not start with process modeling that deals with existing or future organization This approach will limit innovation capabilities It will be very difficult to assess the alignment of

organization with business goals

31


Design approach for processes

Analyse

Seconde analyse

Envoi

Réponse #1:

Réponse #2:

[Demande]

Activity DiagramState machine“Demande”

Demande

Réponse #1

Réponse #2

démarrer/démarrer()

analyse/analyse()

seconde analyse/seconde analyse()

envoi/envoi()

Rôle 1: Rôle 2: Rôle 3:

Analyse

Seconde analyse

Envoi

Réponse #1:

Réponse #2:

[Demande]

Activity Diagram with swim-lanesDesign of process (BPM)

Lifecycle of Business Object

(semantic aspect)

First version of the process: conceptual

process!

Automatic!

Organization processes

Benchmarking!

32


Logical Aspect SOA is located at the level of the logical aspect of

Praxeme’s Topology

As owners of information system Business users must understand principles of service

oriented architecture Being able to evaluate the quality of the system, to evaluate the

reusability…

In most cases the term “service” is ambiguous Collaborative working between Business and IT specialists

require more precise terms Three types of services are identified : GUI service,

organizational service, business service

33


Types of services

Logical Organizational Service (LOS)

Use-case = micro-process

Process




GUI service GUI service

Enterprise Business Service

Logical Business Service (LBS)

Business Object

Atomic service


Business Object

Atomic service


Business Object

Atomic service


Business Object

Atomic service


Business Object

Atomic service


Business Object

Atomic service

Numerousvariants

Steady

34


Urbanization and SOAUrbanization is a metaphor used for logical organization of the IS – Kind of IT City Planning and Enterprise Architecture

35


Urbanization Urbanization brings

A functional map that describes either the existing system or targets

A high level view of IS dedicated to business executive rather than IT specialists that deal with operational project and delivery software

Benefits Easy reading of the IS functional architecture Useful tool for strategic thinking about high level evolutions

of the IS

Drawbacks The functional approach is not helpful for removing data and

redundant functions The functional approach is unable to bridge the gap between

urbanization issues and needs of projects (design by contract, design of components and services)

36


Enterprise method and IS urbanization

With help from enterprise method and SOA, urbanization is located at its right place (logical architecture). This urbanization takes over functional domains and adds business object domains

37


Functional domainsP

re-m

od

elin

g

S?mantiqueSemantic


Functional domains that come from usual IS urbanization


38


Enterprise method and IS urbanization

The enterprise method integrates a map of Business Objects that lays the foundations of semantic modeling

39


Domains of business objectsP

re-m

od

elin

g

S?mantiqueSemantic


Domains of Business Objects


Functional domains that come from usual IS urbanization

40


Examples of models

Gestion des Sinistres

Gestion du missionnement

Gestion de trésorerie

Gestion de l'archivage

Support

Semantic Pragmatic

RéalitéCatalogue

Portefeuille

Prestation

TrésorerieComptabilité

Domains of Business Objects


Functionaldomains

41


Urbanization and SOAP

re-m

od

elin

g



SOA Logical ArchitectureOwned by user and IT specialists


42


BPM and SOA

43


Business Process Management

Goals: with help from a user friendly tool being able to design and execute processes without involving IT specialists Better documentation Stronger alignment of Business with software More resilient IT architecture with help from software

packages dedicated to process execution

Several levels of BPM Process = workflow = Human oriented BPM Use case (micro-flow) = Application centric BPM State machine of Business Object = Application centric BPM Inside a component = IT orchestration of services Between applications = BPM embedded in ESB

(Enterprise Service Bus)

44




Process




GUI service GUI service

Enterprise Business Service


Business Object

Atomic service


Business Object

Atomic service


Business Object

Atomic service


Business Object

Atomic service


Business Object

Atomic service


Business Object

Atomic service

Several level of BPM

Human oriented BPM (workflow)

Screen orchestration

Application centric BPM

IT orchestration



45


Example of a BPM oriented application

Ouvert en gestion

Déclaré

Annulé Périmé

Terminé

Décrit ouvert ré-ouvert

Terminé avec réglement

Terminé sans réglement

/purger()


Couverture évaluée/ré-ouvrir()^Sinistre ré-ouvert

Couverture fermée[Toutes couvertures fermées]/fermer()

[Au moins un règlement]

[aucun règlement]


/déclarer()

Couverture évaluée/ouvrir()

/annuler()^Sinistre annulé

/décrire()

/décrire()

[Contrat, dommage et famille décrits]/décrire()

/décrire()

State machine for the Business Object ‘Claim’

Automatic generationof the code (MDA) Runnable process

46


Agenda




Encouraging agility




47


Pre-modeling

48


Pre-modeling – Key points

Designing screens in the form of reusable graphical atomic components that implement activities

Dissociating business rules from organizational rules

Setting up a dictionary of terms

Setting up a rules repository tool

49


Pre-modeling Activity specification

Reusable graphical component

View specification Assembling activities so as to create page Use case in display mode

Business Action specification Changing the state of the system Atomic transaction concerns Use case in update mode

Process specification Interaction between several actors and/or system during various

periods of time Long running transactions concerns

50


Example of pre-modeling(detailed functional specification)

Activity Mash-up Business Action


Atomic operation – Highly reusable without

database transaction

Building composite application

Specification of business actions with data base

transaction (commit, rollback)

51


Business transaction management

Lock of the logical data that compose the main data flow for this Business Action. In most cases this is the main Business Object that is handled by the Business Action

Release of the lock

ACTE DE GESTION = Transaction métierBUSINESS ACTION = Business transaction

Activité 1 Activité 2 Activité 3 Activité 4

CONTEXTE

BSD

Centralisation des MAJ

en base de données

Activité ‘a’

Start of the Business Action End of Business Action

Activité 1Activity 1 Activité 2Activity 2 Activité 3Activity 3 Activité 4Activity 4

CONTEXTECONTEXTE

BSDBSD

Updates are centralized1 point of commit to the database

Activité ‘a’Activity ‘a’

52


A method shared by business users and IT specialists

53


Unified notation The same UML notation from requirements capture to

software design Encouraging the alignment of business with software Capitalizing of business and organizational knowledge

A capability of modeling by business users Upstream models (semantic, pragmatic) are owned by

business users. They must be able to validate models not necessarily to design them

In most cases, designing of upstream models is delegated to IT specialist, more rarely done by business users with help from IT specialist, and never done directly by business users. Obviously this remark is also valid for process modeling (pragmatic aspect) with BPM tools

54


Examples of UML notationGestion des Sinistres

Déclarer un sinistre

Décrire un sinistre

Traiter les opérations financièresEffectuer une présentation

Affecter un intervenant

Relier les sinistres

Répartir les charges et provisions par garantiesGérer les présentations

<<extend>>

<<include>>

<<extend>>

<<extend>><<extend>>

<<include>>

<<extend>>

<<machine organisation>>

MoAffecterIntervenant


MoDeclarerSinistre


MoDecrireSinistre

<<interface>>

ISignification


MoGererPresentations


MoEffectuerPresentations


MoRelierSinistre


MoRepartirCharges


MoTraiterOperationsFinancieres

<<interface>>

IPresentation

<<interface>>

IFlux

<<interface>>

ISinistre

<<interface>>

IOrganisation

<<interface>>

IArchivage

Use caseOwned by Business users

UML diagram of logical components

Owned by IT people

Two different models that describe

the same concern!Derivation by MDA


55


Adoption of models Upstream models (semantic, pragmatic) must be linked to rules that are

detailed at pre-modeling stage

Linking models to requirements allows to check the quality of the design. Example : “Claim entry” is linked to rules and messages that are described in the requirement module of UML CASE

56


Ergonomics

57


Ergonomics benefits with SOA

In the context of siloed systems Processes are reliant on boundaries between

functional and technical silos: multiple data keying, heterogeneous GUI, no seamless processes, etc.

With help from SOA Processes are better integrated because they

orchestrate services that are not reliant on boundaries of existing systems

A same GUI component can be reused in several applications so as to facilitate learning of systems by business users

58


Ergonomics styles

Either procedural The more usual around functions of the system

Or business folder oriented Users select business objects (contract, customer,

disaster, etc.) and afterwards interact with processes In most cases this approach is encouraged with SOA

59


Ergonomics and use cases By Dominique Vauquier(www.praxeme.org)

• Déclarer sinistre

• Décrire sinistre

• Sélectionner couverture

• <<include>>

• Missionner

• Affecter les intervenants

• Traiter les présentations

• <<include>>

• <<include>>

• <<include>>

• Relier les sinistres

• Répartir les charges sinistre

• <<include>>

• <<extend>>

• Effectuer une présentation

• Abandonner/Modifier une présentation

• <<extend>>

• <<extend>>

• Payer• Encaisser

• Régulariser sinistre

• <<include>>

• <<extend>>

• <<extend>>

Main screen

Secondary windows

Declaration of insurance claim

Financial management

Relationship with others companies

60


Project packagingand SOA

61


Life-cycle is not compelled byPraxeme’s Topology

Example of a usual life-cycleP

ré-m

od

élis

ati

on

LogiqueLogiqueS?mantiqueSémantique

PragmatiquePragmatique

G?ographiqueGéographique Mat?rielMatériel

TechniqueTechnique

LogicielLogiciel

PhysiquePhysique

LogiqueLogiqueS?mantiqueSémantique

PragmatiquePragmatique

G?ographiqueGéographique Mat?rielMatériel

TechniqueTechnique

LogicielLogiciel

PhysiquePhysique

12

3

4

3


62


Key concern

How to deliver a part of the future IS while ensuring A high level of abstraction The ability to integrate this part in the future big picture

of the new IS

63


Incremental delivery By Dominique Vauquier(www.praxeme.org)

Aspect Perimeter

Semantic

Pragmatic

Logical

Technicalet Hardware

Softwareet Physical

The whole perimeter but not in a deep analysis

Detailed analysis only on a sub-area of the system

Deriving upstream models to obtain services specification

Implementing software

64


Agenda




Encouraging agility




65


Agility

With help from composition of existing services, new processes can be developed quickly and easily

Existing services can be modified easily so as to create variants of services Product customization Reference data filtering Pricing table configuration Mail customization (polite phrase, logo, etc.) Rules customization Etc.

With help from rules and parameterization, services can be configured without modifying the software and without systematic involvement of IT specialists

VARIANTE

66


The Agility Chain Management System

“The chain is only as strong as its weakness link”

“No processes without rules and no rules without reference data and parameters”

ACMS (Agility Chain Management System)

MDM1

BRMS BPM2 3

Configuration

Copyright Orchestra Networks

MDM : Master Data ManagementBRMS : Business Rules Management SystemBPM : Business Process Management

• Streamlining master data and parameters management

• Supporting parameterization models allowing variants of execution

• Rules use master data and parameters

• Pre- and post-conditions of organization services are located in the business rules management system

• Processes are sequenced by rules located in the BRMS

• Services that are launched by BPM are parametered using MDM

67


The agility chain

New version = code modification (software impacts)

Variant 1

Variant 2

Variant N

Variant 1

Variant 2

Variant NMD

M, B

RM

S, B

PM

MD

M, B

RM

S, B

PM

Service V1 Service V2

Par

amet

eriz

atio

n

Par

amet

eriz

atio

n

68


Example of BRMS (Ilog Jrules)

69


Example of MDM (Orchestra Networks EBX. Platform)

Example of a print management reference data and parameters

70


Data governance

Life-cycle management (version and variant of data)

71


Agenda




Encouraging agility




72


Batch and SOA

Encouraging real-time operations rather than usual and classical batch treatments

Batch treatments reuse real-time services Unless limits and constraints in time response

IT transaction must be managed by a parameterization mechanism in order to easily change the transaction scope In real-time processing : 1 transaction= 1 Business Object In batch processing : 1 transaction= N Business Objects

73


Software package andSOA

74





TechniqueTechnical

LogicielSoftware

PhysiquePhysical




TechniqueTechnical

LogicielSoftware

PhysiquePhysical

Software package and SOA

The software package is located in the Software Aspect of the Praxeme’s Topology


Software Package

75


Software package and SOA

Semantic and Pragmatic modeling must be maintained in order to keep control of the business and organizational knowledge

At the level of Logical Architecture Business: Does the software package cover one or several

domains of business objects? Organizational: Does the software package cover one or

several functional domains? Can we use only useful domains of the software package or

not?

How agility chain is taken account with BRMS, MDM and BPM ? Do these IT components exist? Are they reusable beyond

software package’s boundaries?

76


Agenda




Encouraging agility




77


What are the quality criteriaof the SOA system?

78


What are the quality criteria of the SOA system?

Number of available tests by service Number of corrections done by period Number of functional evolutions done by period Reuse rate of services Alignment of models with software Number of rules that are located in the BRMS

compared to rules directly hard-coded in the software

Etc.

79


Risks

80


Risks of failures with SOA IT specialists discover services without Business involvement

In this case services wouldn’t be right ones Business users have to design business (semantic) and

organizational (pragmatic) requirements with help from IT specialists (see above), relying on UML notation and a proven and strong method such as Praxeme and supplementary life-cycle management methods and/or frameworks like TOGAF, UP, CMMI, etc.

Insufficient semantic and pragmatic modeling efforts Confusing business with organization issues Forgetting to take into account variants of services

Designing and implementing rigid services Avoid it! This is a huge danger because a more rigid system that

existing IT assets might be unfortunately created Variants of services and separation of concerns (business,

organizational issues) are required to reach a real IS agility

81


Risks of failures with SOA

Failure to streamline reference data and parameters In this situation services will convey low quality data

Failure to establish mixed teams composed of business users and IT specialists IT infrastructure bring feasibility conditions but SOA can’t be

succeeded only with an IT approach

Failure to establish mixed teams composed of senior and junior IT specialists Seniors IT specialists have huge functional and method

knowledge. Companies must take profit of this knowledge before their retirement

Juniors IT specialists need opportunities to leverage their capabilities in modeling, method and they need to enhance their functional knowledge

82


Risks of failures with SOA

Failure to properly utilize IT and modeling proficiencies Everybody is Architect, Designer, Urbanist, BPM expert,

Java specialist, DBA, etc. Tasks that are required to build a SOA have to be

streamlined

Failure to recognize organizational impacts on IT department Moving from siloed systems to the SOA requires a few

changes in the organization of IT department Reinforcement of transversal IT units of work: method,

technical architecture, logical architecture New units of work dedicated to the management of domains

of Business Objects (semantic modeling) Etc.

83


The financial value of SOA

84


The financial value of SOA

SOA brings a method framework that allows for mastering risks of projects regarding the overhaul of IS

Cosmetic SOA doesn’t change existing IT assets. This is just a first step because the value of Cosmetic SOA is reliant on the quality of existing systems. Be aware that this SOA might not provide huge ROI

Overhaul SOA allows for modifying existing IS and building new nimble systems. Be aware that Overhaul SOA requires a huge effort in modeling (semantic, pragmatic), relying on proven technologies that enhance the agility of systems, in particular Master Data Management (MDM), Business Rules Management System (BRMS) and Business Process Management (BPM)

85


The financial value of SOA SOA financial benefits

With help from the enterprise method, SOA streamlines the project management regarding the overhaul of IS

With help from agility software packages (MDM, BRMS, BPM) and the proven enterprise method (semantic and pragmatic modeling, using of variants of services, etc.) costs of maintenance are dramatically decreased. Thanks to the parameterization of services, Total Cost Ownership of modern systems is streamlined

Others strategic benefits Taking over the knowledge of IS. In most cases, this is a strategic

point because of retirement of IT specialists Overhaul SOA with help from agility tools (MDM, BRMS, BPM), that

is to say Extended SOA, allows for aligning quickly business with IT systems. In most cases, this is a strategic point because of interconnection between companies, multi-channels deployment, creating of new products relying on aggregation of various offerings (products and services) etc.

86


Thanks

87


Examples of uses-cases

Pragmatic aspect


88


Examples of activities

Pragmatic aspect


89


Example of models

fRealite

fPortefeuille

fCatalogue

fTresorerie

fPrestation

aSinistre

aPersonne

aObjet

aProduit

aContractualisation

aTransaction

aGeographie

aFlux

aMissionnement

aPresentation

Logical

90


Process UML notation By Dominique Vauquier(www.praxeme.org)

Manager ressources

Administra-teur

Collabora-teur

Enregistrer une compétence

Émettre une demande

:Sème[Non

rattaché]

Statuer sur une demande

:Sème[Rattaché]

Refus

Re-déclarer une compétence

Éditer le bilan des

compétencesBilan des compétences

[Thème inexistant]

[Demandeacceptée]

[Demanderefusée]

Fin de mission

Anni-versaire

Swim-lanes

Catching event

Activity

Object(instance of a business class)

Throwing event Conditional branch

Actor(Type of actor,role)

SITA PXM BU Overview IS

Documents

Transcript of SITA PXM BU Overview IS