Praxeme

1
Praxeme

• A comprehensive Introduction to

A Methodology for the Design of Sustainable
Enterprise Systems This version has been
prepared and is presented by Bernard Hauzeur,
independent ICT Architect (bh_at_artofe.biz)
2
Front matter

• Acknowledgements
• License (legal)
• Pointers
• Objectives

3
Acknowledgements

• This version has been compiled from
• materials from the Praxeme institute
  (www.praxeme.org)
• the presentation of the methodology available
  from http//www.sustainableitarchitecture.com/mate
  rials and http//www.orchestranetworks.com/fr/soa/
  
• a compilation by Fabien Villard _at_inno.com
  (http//www.praxeme.org/DocumentsEnAnglais/Introdu
  cingPraxeme.Inno.2009.04.17-01.pdf)
• plus original contributions
• The methodology has been originally designed by
• Dominique vauquier, methodologist,
  www.praxeme.org
• Pierre Bonnet Orchestra Networks

4
License

• This document is published under a Creative
  Commons license, with the following attributes
• Praxeme and Praxeme Institute
• are registered trademarks

( http//creativecommons.org/licenses/by-sa/2.0/fr
/deed.en )
5
Pointers

• Sites
• http//www.praxeme.org
• http//www.orchestranetworks.com/fr/soa/
• http//www.sustainableitarchitecture.com/
• http//www.mdmalliancegroup.com/
• Books
• "Le système d'information durable la refonte
  progressive du SI avec SOA " by P Bonnet, JM
  Detavernier, D Vauquier
• "Sustainable Architecture the progressive way of
  overhauling information systems with SOA" idem

6
Objectives

• Understand what makes PRAXEME different, and why
  how this methodology does obtain outstanding
  results

Audience

• IT specialists with some methodological
  background, exposed to modelling, and UML in
  particular
• eager to discover at least one method that can
  help design Service Oriented systems other than
  by the empirical grouping of data accessors,
  activities, and bits of functionality into
  services tied together with BPM glue

7
Positioning PRAXEME
8
The Context

• You know the mess

at minimum, if we keep trying why not with
Praxeme?
9
The Scope

• How do we organize this?

Users
Interfaces
?
Workflow
Services
?
...other than by just experience, best practices,
and love for brilliant works
?
Data
10
The PRO3 Scheme
Why?
Goals
Product
Procedures
Processes
How?
11
The main contribution of PRAXEME is about
PROcedures

• comparison based on main focus

12
Is there an architecture matching PRAXEME ?

• yes SITAF
• Sustainable
• IT
• Architecture
• Framework

13
which you may compare with the usual
Functional and Technical silos
?
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
?
14
Functional silos generate redundancies
Order entry
Customer care
Duplication of updating address Different
GUI May be data duplication related to address
management
Selecting product code
Score analysis
Choosing quantity
Sending mail
Calculating discount
Updating address
Updating address

• numerous techniques and products attempt to
  identify and reduce these redundancies, yet they
  do not solve the problem at the core.

Using Business Objects and SOA, urbanization is
enhanced and redundancies can be removed
15
The face of change
Logical architecture diagramfollowing SOA
Sample architecturebased on functionnal approach
FD
FD
FD
FD
OD
OD
OD
BO
BO
BO
BO
OD
OD
FD
FD
FD
FD

• Logical blocs based on Functional Domains
• from a pragmatic and historical model
• Strong interdependencies and redundancies
• Business Objects are found multiple times
• All components may be linked to others

• Logical blocs based on Objects Domains
  structuring
• the semantic model
• Dependencies linked only with topological
  constraints
• From organization stratum to business stratum
• Mutual relations are forbidden
• No dependencies between OD blocs.

16
SOAoverhauled with PRAXEME
17
PRAXEME does not re-invent the wheel!

• Good sense at the base decoupling,
  encapsulation, separation of concerns,
  abstraction, contractualization, testing,
• PRAXEME reuses all the knowledge inherited from
  object oriented design
• no other formalism than available in UML is
  required
• but the way to use all of that is quite original!

18
What makes PRAXEME different?
19
PRAXEME reverses the way you design systems!

• The usual way
• top-down hierarchical-functional decomposition

• PRAXEME
• by DERIVATION, following the curve of the sun

20
The right starting point

• Process modelling is limited
• Penalized by local variations
• Favours redundancy

Business Objects, real objects (InformationTransf
ormationAction)?
Actors and organizational Entities Processes and
Use case
21
The right structure for the system
Semantic Aspect
Objects
States
Derives from
Business Objects, real objects (InformationTransf
ormationAction)?
Partly derives from
Derives from
SOA style
22
The magic in PRAXEME is its use of DERIVATION
rules

• Illustration the 4 derivation paths originating
  from the semantic model

IS Structure Info Flows through services
ISStructure Service boundaries
Data Modeling
Semantic Model
Logical Aspect
Pragmatic Aspect
Process Modeling
23
The magic in PRAXEME is its use of DERIVATION
rules

• A more comprehensive view

Semantic Model
24
DERIVATION also affects the way you build
operate systems
Semantical and logical reference models
TRACEABLE

• GOOD

• BAD!

25
and this is the Path to 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

26
and the path to Incremental Delivery
The whole perimeter but not in a deep analysis
PRAXEME
Perimeter
Aspect
Detailed analysis only on a sub-area of the system
27
The PRAXEME Framework

• The Enterprise System Topology
• (E.S.T.)

28
The framework is mostly about organizing
derivation activities
29
Enterprise System Topology
30
Enterprise System Topology
models
implem-ents
derives from
hosts
refers to
depends from
derives from
models
maps to
distributes
models
deployed on
equips
31
Reading the EST

• Arrows represent dependencies between aspects
• A package references content from another one
• OR
• A package is derived from another
• One notable exception Tech depends from Soft?
  No!
• Technical Aspect gives
• Technical choices
• Recipes to use the technologies
• Arrows are oriented
• Missing links
• May carry more meaning than existing links
• Forbidden dependencies
• The EST supports traceability

Warning!
32
Topology Macro Structure
33
Upstream Aspects

• Semantic Aspect
• The core business knowledge (data, logic, rules,
  states, relations)
• Organized in Business Domains
• Pragmatic Aspect
• How an enterprise acts in its business domain
  (use cases, activities, processes, admin data,
  life-cycles)
• Organized in FunctionalDomains
• Geographic Aspect
• Geographical constraints,localization of
  activitiesand systems

34
Logical Aspect
SOA-style Logical Architecture Owned by Business
and IT specialists
'Maîtrise d'Ouvrage' tells what to achieve
'Maîtrise d'Oeuvre' implements it !
35
Logical Architecture(SOA style )
36
Downstream Aspects

• Physical Aspect
• Mapping software onto servers / processes /
  threads, onto HW (deploy)
• ?Failover, Load-Balancing

• Technical Aspect
• Execution environment (OS, persistence,
  transactions, containers, security)
• DB, ESB/middleware, BPM, MDM, BRMS, IAM,
• Human Interface technologies
• Software Aspect
• Code structure, packages, rule sets,
  storedprocs, meta-data, data bases, all software
  artefacts
• Assemblies / components
• Referential
• Hardware Aspect
• Machines, networking

37
Life-cycle

• Example of a usual life-cycle

1
4
2
3
3
38
The "curve of the SUN"
Aspects
Strategic orientation
Semantic Pragmatic Logical Software Physical
Business referential
Existing Activities
Improved Processes
Existing Data Models
Services Architecture
Cartography of Existing Applications
Components
Time
collecting informa -tion and preparing migration
innovation zone
39
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

40
Software package and SOA

• The software package is located in the Software
  Aspect of the Praxemes Topology

Software Package
41
Its time forQuestions Answers

• Thank you!
• Bernard Hauzeur (bh_at_artofe.biz)