CLHYPS-EA - R&D Perspectives - 20150210-a-EN-short

© Jean-Guy SAYOUS 2000-2014 – All Rights Reserved - Tous droits strictement réservés
Conciliation of Enterprise Architecture related
models through algorithmic transformation of
business requirements models
The CLHYPS-EA method
Designed by : Jean-Guy SAYOUS
j-g.sayous@orange.fr
+33 681 313 874 (Mob)
Presentation

• Introduction
• CLHYPS-EA - Problematic
• CLHYPS-EA – Toward a formal solution
• CLHYPS-EA – Opportunities & Challenges
• CLHYPS-EA – First overview of the capabilities
Agenda

Introduction
• Jean-Guy SAYOUS - Background
• CLHYPS-EA/(SA) (R&D) project objectives
• Possible partnership framework(s)

• PhD, Physics – Master, Software Engineering
• CLHYPS-EA methodology designer
• Previously owner and CEO - JGS groupe (2000 - 2011)
• European and global operational and managerial responsibilities, in the area of
information system engineering and architectures, notably at:
– Dassault Aviation - Technicolor (ex Thomson)
– General Electric (GE Healthcare)
• In France, various contracts for consultancy and training at, notably:
– Caisse des Dépôts Veolia Eau Télédiffusion de France - TDF
– Aéroports de Paris SNCF Pierre Fabre Médicaments
– Orange Groupe CAILLAU SPERIAN Protections…
• Since 1994, visiting professor at ISTY, the engineering school of the University of
Versailles Saint-Quentin:
– 2002-2008 Deputy Director
– 2010-current Development magager
Jean-Guy SAYOUS’ background

• To design and to develop the first version of a platform, supporting a
new formal methodological framework - CLHYPS EA -, enabling the
conciliation of models related to the area of Enterprise Architecture
• The conciliation results from an algorithmic transformation from one
canonical reference event-oriented model: the business requirement
model
 «Automatic» production of most of the models currently in usage in the area
of EA
• Metamodel based on a generic semantic, able to suport different
modeling syntaxes (Archimate, UML, SysML, IDEF…)
 Easily scalable to models related to the area of System Architecture
• (Re)use of standards: TOGAF, BPM, UML/SysML, Petri Networks…
• …as well as existing plateform(s)
CLHYPS-EA – Project objectives
Actual disruptive change of paradigm capitalizing on and
reinforcing the already acquired modeling related knowledge

• Training and coaching package (Already mostly available)
• Strategic development plan for next releases:
• Version management
• Internationalization (but if done…)
• Change requirements management
• IAM related models
• Configurations management
• Data migration plans
• Tests/qualification plans
• Simulation
• Proposed strategy for patent (IP) rights
• Primary patent for the innovative claims related to version 1 to be registered asap
• « Related » (secondaries) patents to be registered « asap », prior to any new
version
Introduction - Project objectives
Mastering of the patent right…
…Change management in ecosystem under control
Requirement model oriented
Cross-functional topics

• Gouvernance : partenership
– Type of partnerships Mutual agreement
Pôle(s) de Compétitivité
IRT – (French) Institute of Research in Technology
Chair (foundation, university…)
Others…
– « Big companie(s) » Funding sponsorship/« Industrial » guarantee
– SMB/SME Solution subset/operational contribution
– Laboratory(ies) « Scientific » guarantee
• Funding - Resources
– « Industrial » funding: « customer » companies, software editors, consultancy
companies, engineering companies…
– Institutional funds (BPI…)
– « French competiveness hubs » (pôles de compétitivité )
– « French Investment for future » (investissements d’avenir)
– « Tax-research credit » (crédit impot-recherche – CIR -)
– ANRT – « CIFRE » agreements (to fund PhD theses) – ANR..
– European Community funds…
Possible partnership framework(s)

Key concerns
• Statement
• About the compartmentalization of the modeling practices
• About the compartmentalization of the transformation process
• About the reactivity of the EA function in the transformation
process
• Some consequences

• Why do the following points still remain a concern nowadays?
– Alignment of the information system capabilities to the strategy and the operations
– Consistency of the digital solutions to the business requirements
– Effectiveness of the mastering of business changes
– Effectiveness of the operational efficiency and of the added value of the enterprise
architecture function
– Quality of the relationships between the IT related functions and the business ones
– Effectiveness of the project management related activities (scope, costs, planning)
– …
• Some of the key root causes are:
– Strong ruptures between the modeling practices of different communities
(business analyst, architects, IS designers,…)
– Resulting mainly from the previous cause:
• the discontinuities in the process aiming at delivering, the detailled
specifications required to operate effective transformations
• The current incapacity of the EA function to be proactively operational at the
very beginning of transformations
Key concerns
Statement
Causes resulting mainly from the current inability to conciliate the
different points of view that express each of the various models

• Compartmentalization of the modeling practices (architecture and
transformation)
 Diverging communication between the communities/actors - Misunderstanding
 Non-conciliated models – Discrepency; inconsistancy
 « Over time », loos of utility of models, then/therefore of modelization…
• Compartmentalization of the transformation process « from business
requirement to operational solution » (organization, digital solution…)
 Divergences/« loss of semantics » while « passing the baton »
 Discrapancies between « solutions » and « requirements »
• Compartmentalization between the EA related activities and the
transformation related ones
 Reactive EA instead of PROACTIVE EA
 No/few EA models at the initialization of the transformations
 EA function overloaded because of too late updating of the EA models (at the end
of transformations) –
 STRUCTURAL desynchronization « transformation » Vs. « architecture »
Key concerns
Three key ruptures

Key concerns
Compartmentalization of the modeling practices
Non conciliated models – Different laguages – Loss of semantics
Business objects model
« Applications » mapping
Application architecture
& applications cartography
Business Process
cartography
Business Process
Architecture Model
Enterprise Architecture area
Business requirements model
Business process/activity model
« Business Process
Mgmnt » Area
Application
Architecture
& Planning
area
Business
Transformation
(Process & IS)
Area

Requirements
Elicitation
Req. Analysis
Bus. Process &
IS functional
DESIGN
Key concerns
Compartmentalization of the transformation process
Org. changes
planning Deployment
(org. & IS)Digital IS
development
EA’s involvement « limited » to governance
• Different actors at different steps – EAs apart from the actual action
• Irregular, fragmented knowledge transfer from one step to the following
• Increase of the lack of consistency between models
• Lack of consistency between the design and the implementation of
solutions…
IS and business activities not aligned…
Effective added value of the EA function questionned…

• Business requirements model
• Business process (activity) model
• Business objects model
« Transformation rythme » >> « EA rythme »
 Inability to synchronize « EA » artifacts with « Transformations » ones
 Discrepancy between actual solution and EA models
 Weak impact analysis capabilities
 Difficulty to master the scope of new transformations…
Key concerns
Compartmentalization « EA » - « Transformation »
EA not involved in the
transformations - EA specific
requirements not handled
Few/no contribution to the initialization of the transformations – Shallow models..
Weak integration capabilities because too much transformations to manage…
EA operates in a REACTIVE mode => « Away » from the transformations
• Business processes cartography
• Business process architecture
• Applications cartography
• Application architecture
Enterprise Architecture Repository
Business requirements; objects; process/activity models
Enterprise transformations

• Overrun of costs and shedules of transformations – Scope weakly mastered
• Weak QoS: Poor customer satisfaction and confidence due to incompatibility
between « solutions » and « requirements »; rigidity facing the business
changes; poor scalability of the solutions…
• Uncomplete requirement specifications leading to « risky » transformations
(organization & IS)
• Weak mastering of the overal complexity of the solution
– Solution (organization & IS) not aligned on the operational activities, therefore
on the business strategy
– Lack of consistency therefore of confidence in the quality of the information
• EA function operates in a REACTIVE way, not PROACTIVELY while
transformations occur
– « Very light » operational involvement during the transformations
– Effective EA added value challenged
• Transformations operated in a « siloed » and « phased » way
– Loss of semantics accross the boundaries
Key concerns
« Some » of the consequences

CLHYPS-E(S)A : Toward a formal solution…
• « Requirement centric modeling approach »: Conciliation of models
• Re-engineering the « Requirements transformation process »: Reducing
the discontinuities
• « an EA-oriented Transformation (too) »: Toward an actual continuous
Enterprise Architecture improvement

CLHYPS-E(S)A – Toward a formal solution
Requirement centric modelling – Formal conciliation of models
Business process/activity model Business objects model
« Applications » mapping
Application architecture
& applications cartography
Business Process
cartography
Business Process
Architecture Model
« Requirements management »
Area
Business requirement model
« Enterprise Architecture » area
« Business Process
Mgmnt » Area
Application
Architecture
& Planning
area
Business
Transformation
(Process & IS)
Area
Conciliated models – Common language for the « requirements »
Shared semantics

Re-engineering the « Requirements transformation process »: Reducing the discontinuities
Requirements elicitation &
analysis
Bus. Process, IS functional
design & EA models
GENERATION
Org. Changes
planning
Digital IS
development
Requirements
Elicitation
Req. Analysis
Bus. Process &
IS functional
DESIGN
Org. changes
planning Deployment
(org. & IS)Digital IS
development
From « transformation dependant » EA …
EA op. mgmnt
Deployment
(org. & IS)
« Requirement AND EA oriented »Transformation
Information system and operational activities aligned
… to « EA oriented » transformation (too)

BP2M
URBA
A&D
CLHYPS EA
Exploitation
Projects
« EA oriented » transformations => an actual continuous EA improvement
Transformations pilotées
par l’architecture
Effective initialization
capabilities
« A priori » intégration
of the transformations
Effectively PROACTIVE EA => « leading » the EA transformations
• Business requirements model
• Business process (activity) model
• Business objects model
EA involved in the transformations
EA specific requirements handled
• Business processes cartography
• Business process architecture
• Applications cartography
• Application architecture
Enterprise Architecture Repository
Business requirements; objects; process/activity models

CLHYPS-EA : Possibilities and challenges
• Opportunities and benefits
• Challenges

• Same as those already identified for the EA function…
• Beyond, quantifiable savings and benefits, on an economical stand and on a
qualitative stand point
• Economocal stand point, (notably) :
– Dramatic cost and workload cuts while producing the business objects and business
activity/process models: At least 50%
– Very significant time and workload reduction while updating the EA specific models
• EA models effectively updated and consistent with the actual solution
(organization and IS)
– Ability to produce « systematically » functional and integration tests scenarios
– Very significant bugs reduction therefore bug fixing cost savings…
CLHYPS E(S)A – Possibilities & challenges
Opportunities and benefits
Possibility to produce easily an actual business case…

• Quality stand point, resulting from the formal aspect of the modelization and of
the conciliation of models:
Quality of the solution
– Rationality of the business requirements formalization: Focused on the functionning of
the operational context, which characteristic interactions are rigorously described
– Each EA model constistent with each of the other ones
– Effective modular EA
– Formal approach for identity and access management – IAM -…
Quality of the « transformation process » and its steering mechanismes (PMO)
– Scope of transformations mastered and formally specified
– « Objectification » of the relationships between actors - Operational communication
effectively improved
– Mastering of the strategy of integration/roll-out of the transformations
– Project plannings and follow-up, cost estimates, risk management: rigorous tasks
outputs specifications
– Quality assurance and control: dramatic reduction of the inter-model validation
nessecity; rigorous inventory of the test cases and generic structure for their
specification…
– …
Opportunities and benefits

Paradigm change: Requirement engineering instead of functional design
engineering
– Consulting companies, in the area of « EA » or engineering of processes or
information systems
• Change of business plans
• … but dramatic increase of the productivity and of the competitivity
– Companies, organizations
• Require actual collaborative management, based on confidence and delegation
• Actual involvement of the « EA function » on operational transformations; not only
within steering committees!
• Progressive set-up of a digital information system (platform) dedicated to the
Knowledge Management (KM) of the overall EA, processes and IS modeling activities
• Cultural integration of an actual requirement (engineering) oriented mindset, instead
of a « solution » oriented mindset
– Package providers
• Re-engineering of the architecture of the packages
Significant training and coaching effort
…but reuse of the current competencies
Challenges

CLHYPS-E(S)A – First overview of the
capabilities
• Conciliation of the EA, BA, and IS related models
• A business requirements centric approach: justification
• The business requirements model
• The business objects model
• The business process/activity model
• About business services
• The business processes cartography
• The business process architecture model
• The application architecture model
• The application service architecture model

Business requirements model
Business activity/process model Business objects model
CLHYPS EA : First overview of the capabilities
Conciliation of the EA, BA and IS related models
Applications mapping
Applications cartography
& Application services Architecture
Business processes cartography
Business process architecture

Business requirement model
• Operational context purpose
• Environnement-context Interactions
• Requests
• Reactions
• « Internal » operational interactions
• Requests
• Reactions
• Business information needs
• Operational steps sequencing
• Business management rules
The business requirements model « embed » the semantics that
formalize the other models
« Process »
« Ordered business
interactions »
« Procedure »
« Business services »
« Business objects »
« Application »
« IT services »
« Zone »
A business requirements centric approach: justification

From the business requirements models…
Business interactions
•Types of events
•Types of effects
•Inter processes interactions
•…
The business requirement model

CObj(IODesc)
+DateIODesc
+PlannedStartDate
+PlannedEndDate
+ProcessIVRqst()
+ProcessIVRCancel()
+MFunctIdentifier()
CObj(IVRqst)
+DateIVR
+MFunctIdentifier()
+ProcessIVKo()
+ProcessIVOk()
+ProcessIVRCancel()
IODescRess
+ProcessIODesc()
CObj(IVRCancel)
+DateIVRCancel
+SFuncIdentifier()
CObj(IVKo)
+DateIVKo
+SFuncIdentifier()
CObj(IVOk)
+DateIVOk
+MfuncIdentifier()
+ProcessIARqts()
Student
+TriggerIODesc()
+TriggerIVRqst()
+TriggerIARqst()
+TriggerIVRqstCancel()
+TriggerIARqstCancel()
InternshipComMbr
+TriggerIVKo()
+TriggerIVOk()
*
Rs
InternshipOfferingDescription*
Be
*
1
Ba
*Rs
InternshipValidationRequest
*Be1
Ba
*
*
Be
InternshipValidationOk
*Rs
1
Ba
*
*Be
InternshipValidationKo
*
Rs
CObj(IVRAnswer)
+MfuncIdentifier()
* Rs
InternshipValidRqstCancellation
*
Be
1Ba
*
Student
+TriggerIODesc()
+TriggerIVRqst()
+TriggerIARqst()
+TriggerIVRqstCancel()
+TriggerIARqstCancel()
CObj(IAR)
+DateIAT
+MFuncIdentifier()
*
Be
InternshipAgreementRqst
*
Rs
*
1
Ba
…to the business object model…
The business objects model

…to the business process/activity model…
The business process/activity model

A first
service
A second one
Another
oneAnother
one
… to the business services model…
About business services

… to the business processes cartography…
The business processes cartography

… to the business process architecture…
The business process architecture model

The application architecture model

The application service architecture model (1)

The application service architecture model (2a)

The application service architecture model (2b)

Thank you !
• For further contact:
– jean-guy.sayous@orange.fr
– +33 681 313 874 (mobile)
– Skype: jgs78460
– LinkedIn: fr.linkedin.com/in/jgsayous/
– Twitter: @jgsayous

CLHYPS-EA - R&D Perspectives - 20150210-a-EN-short

Recommended

Recommended

More Related Content

What's hot

What's hot (15)

Similar to CLHYPS-EA - R&D Perspectives - 20150210-a-EN-short

Similar to CLHYPS-EA - R&D Perspectives - 20150210-a-EN-short (20)

CLHYPS-EA - R&D Perspectives - 20150210-a-EN-short