Your SlideShare is downloading. ×
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
SITA PXM BU Overview IS
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

SITA PXM BU Overview IS

274

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
274
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Version – August 13th, 2007 Pierre Bonnet - Orchestra Networks [email_address] SOA overview and Praxeme insight for Business Users (V2 reviewed by Oscar Chappel from ILOG Company, 2008-02-25) (V1 in English Language) SOA stands for Service Oriented Architecture Praxeme 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:
  • 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 context What 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 code Choosing 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) Semantic aspect Pragmatic aspect
  • 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
  • 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 ../..
    • Variants are declared according to execution contexts
    • Products
    • Processes
    • Right management
    • Rules
    Not SOA! VARIANTE
  • 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 Management BPM : Business Process Management BRMS : 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 Pre-modeling S?mantique Semantic Pragmatique Pragmatic G?ographique Geographic Modeling of requirements Owned by Business users CORE BUSINESS Business Objects Lifecycle of Business Objects Information modeling WITHOUT ORGANIZATIONAL CONCERNS ORGANIZATION Organizational structure Human resources Business processes Uses-cases NOT YET UML but ALREADY REUSE MINDSET!
  • 24. Praxeme’s topology Pre-modeling Logique Logical S?mantique Semantic Pragmatique Pragmactic G?ographique Geographic SOA Logical Architecture (*) Owned by Business and IT People (*) SOA is a style of logical architecture: neither technical architecture nor business architecture
  • 25. Praxeme’s topology Pre-modeling Owned by IT Specialists Logique Logical S?mantique Semantic Pragmatique Pragmatic G?ographique Geographic Mat?riel Hardware Technique Technical Logiciel Software Physique Physical
  • 26. Semantic Aspect
    • Core business
      • Domains of business objects
      • Information modeling
      • Business objects lifecycles modeling
    Figures - SMABTP Project (overhaul in a context of insurance company) Product Contract Service provided - 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 management Customer care…
  • 27. Ex: Lifecycle of Business Objects State machine of “Claim” Business Object Figures - SMABTP Project (overhaul in a context of insurance company)
  • 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
    • 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
    • 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
  • 31. Design approach for processes 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 Numerous variants Steady
  • 34. Urbanization and SOA Urbanization 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 domains Pre-modeling S?mantique Semantic Pragmatique Pragmatic 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 objects Pre-modeling S?mantique Semantic Pragmatique Pragmatic Domains of Business Objects Functional domains that come from usual IS urbanization
  • 40. Examples of models Domains of Business Objects Figures - SMABTP Project (overhaul in a context of insurance company) Functional domains Semantic Pragmatic
  • 41. Urbanization and SOA Pre-modeling Logique Logical S?mantique Semantic Pragmatique Pragmatic SOA Logical Architecture Owned 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. Several level of BPM Human oriented BPM ( workflow ) Screen orchestration Application centric BPM IT orchestration Application centric BPM Application centric BPM
  • 45. Example of a BPM oriented application State machine for the Business Object ‘Claim’ Automatic generation of the code (MDA) Runnable process
  • 46. 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
  • 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 Figures - SMABTP Project (overhaul in a context of insurance company) 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étier BUSINESS ACTION = Business transaction Centralisation des MAJ en base de données Start of the Business Action End of Business Action Activité 1 Activity 1 Activité 2 Activity 2 Activité 3 Activity 3 Activité 4 Activity 4 CONTEXTE CONTEXTE BSD BSD Updates are centralized 1 point of commit to the database Activité ‘a’ Activity ‘a’ Activité 1 Activité 2 Activité 3 Activité 4 CONTEXTE BSD Activité ‘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 notation Use case Owned by Business users UML diagram of logical components Owned by IT people Two different models that describe the same concern! Derivation by MDA Figures - SMABTP Project (overhaul in a context of insurance company)
  • 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
    • 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 packaging and SOA
  • 61. Life-cycle is not compelled by Praxeme’s Topology
    • Example of a usual life-cycle
    1 2 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 Aspect Perimeter Semantic Pragmatic Logical Technical et Hardware Software et 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
    • 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
  • 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 ) Configuration Copyright Orchestra Networks MDM : Master Data Management BRMS : Business Rules Management System BPM : 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
    MDM 1 BRMS BPM 2 3
  • 67. The agility chain Variant 1 Variant 2 Variant N Variant 1 Variant 2 Variant N MDM, BRMS, BPM MDM, BRMS, BPM Service V1 Service V2 New version = code modification (software impacts) Parameterization Parameterization
  • 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
    • 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
  • 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 and SOA
  • 74. 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
    • 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
  • 77. What are the quality criteria of 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 Figures - SMABTP Project (overhaul in a context of insurance company)
  • 88. Examples of activities Pragmatic aspect Figures - SMABTP Project (overhaul in a context of insurance company)
  • 89. Example of models Logical
  • 90. Process UML notation Swim-lanes Catching event Activity Object (instance of a business class) Throwing event Conditional branch Actor (Type of actor, role)

×