Implementation Of Ontological Business Transactions Using Demo And The Normalized Systems Approach (Op T Land, Ist, 16 Jul2012) Final

Implementation of Ontological
Business Transactions using DEMO
and the Normalized Systems approach

Prof.dr. Martin Op 't Land
Innovation Alliance Developer at Capgemini
Professor of Enterprise Engineering at the University of Antwerp Management School

PROGRAMA DE PÓS-GRADUAÇÃO PROFISSIONAL

ANÚNCIO DE CONFERÊNCIA 16 DE
JULHO, 18h00, Anfiteatro PA-3. IST, CAMPUS DA
ALAMEDA, LISBOA

The idea in one sheet
• organizations and IT have fundamentally different change drivers
– only when using the right granularity in understanding organizations and IT, it
will be possible to let them stay connected, while free to evolve
• DEMO theory (well-established): organizational building blocks
– transaction (“molecule”), coordination act (“atom”), actor, action rule, etc.
• Normalized Systems (well-established): IT system building blocks
– elements, cross-cutting concerns
• research area: how to achieve and industrialize new levels of business-IT
“loose coupling” between DEMO and NS building blocks?
– we started working recently with implementation modeling for the well-known
case EU-Rent

Today we want to show you a sneak preview on work-in-progress
Implementation of Ontological Business
Transactions using DEMO and the Normalized July 16th, 2012
Systems approach ©2012 Martin Op 't Land 2

Implementation of Ontological Business Transactions using DEMO and the Normalized Systems approach

Content
• connecting DEMO to NS: organizational  ICT system granularity
• introducing DEMO (if necessary)
• what is Normalized Systems
• the EU-Rent case
– Construction Model
– from Fact Model Eu-Rent to NS CRUDS-screens
– derivation of mockups/screenflow/process flow from DEMO models
• the Coordination world
– uniqueness of a P-fact / proposition
– measurability of the C-act time
– organization dependencies
• conclusions
• future developments
• next steps for you

Let's introduce myself: Martin Op 't Land

• married Cobi Wattez; father (in law) of Norbert (22), Sifra x Thijs-Willem (24), Sjoerd (26)
• Principal Consultant and Certified Enterprise Architect at Capgemini
• >25 years active in mainly Banking and Public, e.g.

• several educational affiliations
– Professor Enterprise Engineering, Antwerp Management School (BE)
– lecturing at Universiteit Antwerpen, TU Delft
– lecturing DEMO Professional

• finished PhD-research@TUDelft 2008
– PhD thesis Applying Architecture and Ontology
to the Splitting and Allying of Enterprises
– Summarized for managers in Instrument for
fast and effective splitting of organizations (NL)
• first book @ Springer (2009)
– Enterprise Architecture: Creating Value by Informed Governance
I like to advance enterprise agility by connecting organization granularity with ICT granularity

Connecting DEMO to NS:
bridging organizational with ICT system granularity

• Normalized Systems can be built, taking common system requirements as
a starting point (e.g., data model, mockup screens, use cases)
• this already creates (ICT system requirements)≅ (NS system-change)
– the 8 anticipated changes of NS are in terms of (ICT system requirements)
• how to create (organization change)≅ (ICT system requirements)?
– start with DEMO as a language for organizational essence at a moment
– map DEMO systematically and coherently to
• organizational implementation (assigning organizations/functionary types, separation of
functions etc.)
• ICT system requirements (mockup screens, screenflows, data model, etc.)
– clarify (DEMO model)  (ICT system requirements)  (NS system-change)
• to create such an industry strength mapping DEMO-NS, on going research
is performed by UA, TU Delft and Capgemini
– earlier work (e.g., patents, grants) by Huysmans, Krouwel, Op „t Land
– today a sneak preview on work in progress … a “prototype” DEMO-NS

DEMO's core-theory
• Operation Axiom
– The people in an organization (subjects) perform two kinds of acts: production acts or P-
acts and coordination acts or C-acts. fact

• Transaction Axiom
requested
request promise

– C-acts and P-acts always occur in particular patterns (OER)
O-phase
desired fact
new fact promised

• Composition Axiom fact
E-phase
fact

– Transactions (which bring about new facts in reality)
accepted produced
customer producer
R-phase
are related to each other in one of two possible ways: accept state
fact

• a transaction is enclosed in another transaction; stated

• a transaction is self-activating.
• Distinction Axiom
– three distinct human abilities play a role in the operation of actors, called
performa, informa and forma.
• Organization Theorem
– an enterprise is a layered nesting of three homogeneous aspect systems: the B-
organization (from Business), the I-organization (from Intellect) and the D-
organization (from Documents)

A DEMO-transaction consists of coordination
and production acts, in which facts are created

coordination production

here production
facts are created

here coordination Kinds of coordination acts
facts are created
success “problems” discourse
T1
request quit revoke

promise decline refuse

state stop allow

accept reject

DEMO’s distinction axiom

Coordination Human Production
as performer as addressee ability
ontological action
expose evoke
(decide, judge, manufacture,
commitment commitment
performa observe)

infological action
express fact educe fact (remember, recall, reproduce,
(formulate) (interpret) deduce, reason, compute,
informa etc.)

perceive datalogical action
utter sentence
sentence (store, transmit, copy,
(speak, write)
(listen, read) destroy, etc.)
forma

A DEMO model of a B-organization
consists of 4 aspect models
Actor A07
inspects facts from
transactions T01
S01: S01 system border

Construction Model A07
T07 actor A07

B- transaction T07
organization
CM
A00 A01

actor A00
T01 actor A01
I-
organization
Process Model PM SM State Model transaction T01

A00 is initiator of T01 A01 is executor of T01
D-
organization AM

Action Model

Using DEMO´s CM is already a great help in reducing complexity and focusing attention

Several real-life cases suggest significant
benefits of DEMO in governing transformations
where Effort Return
ROOD 5 weeks for CM, well-underpinned re-allocation of
½ day GDS responsibilities (5,000)
VISI standard DEMO- rapid design of civil construction
training project organizations
SSC Securities weeks for CM common language for organizational
and ICT-split
NATO weeks for CM basis for Overarching Architecture,
including use cases and SOA
Rijkswaterstaat (RWS) 175 man-days application portfolio rationalization
½ yr proposal, 49% saved (130 apps, used
by 300 staff in 6 regions)
RWS-Deltares several 10s of organization-split proposal + items for
man-days contracting
AFKL Cargo 65 man-days in neutral language, agreement upon
6 weeks design and migration issues

Example: EU-Rent, modeled in DEMO (CM)
Construction personal B-
data APB02
B-
APB01
EU-Rent
data

Model
EU-Rent

B-CA01 B-A01 B-CA02
B-T01 B-T03

rental start rental
car pick-up
starter driver

renter B-T04

car drop-off
B-A02
B-T02

rental B-
rental end APB01
ender
B-CA03
B-T05 EU-Rent
payer data

rental payment

Transaction kind Transaction result
Transaction B-T01 rental start B-R01 [rental] has been started
Result B-T02
B-T03
rental end
car pick-up
B-R02
B-R03
[rental] has been ended
the car of [rental] has been picked-up
Table B-T04 car drop-off B-R04 the car of [rental] has been dropped-off
B-T05 rental payment B-R05 [rental] has been paid


What is Normalized Systems (NS)?

Content Benefits
• Normalized Systems (NS) = • productivity improvement in
systems that can be changed development
without combinatorial effects – factor 2-3 has been proven realistic
– one type of anticipated change will • maintenance improvement even
only propagate in one module better, because NS = top quality
– a given maintenance action on an software
NS-system costs (even formally)
proven exactly as much impact now,
“Our insight in what software quality
or two years later (when the NS-
comprises is changed to such an extent
system is, say, five times as large
that we can no longer imagine to
and complex)
develop good software without
• NS theory and tools developed by Normalized Systems.” (5 well-seasoned
University of Antwerp (UA) developers of Capgemini, 2011)


Background: NS under the hood –
4 Principles, 5 Elements, 8-10 cross-cutting concerns

X-cutting
4 Principles 5 Elements Structuur
concerns
 SoC: Separation of Concerns  Data …
 DVT: Data Version Transparency  Action Remote Persist
 AVT: Action Version Transparency  Workflow
 SoS: Separation of State  Connector GUI Encaps

 Trigger Access
Service
…

With NS, an Application = n instantiations of Elements, fully separated
from each other ⇒ no Combinatorial Effects (CE), ex ante proven*
*Mannaert Herwig, Verelst Jan (2009). Normalized Systems: Re-creating Information Technology Based on Laws for Software Evolvability. Koppa


EU-Rent case
DEMO Construction Model (part)
EU-Rent

Organization B-CA01 B-A01
Construction B-T01
Diagram rental
rental start
starter

renter

B-A02
B-T02
Transaction
rental
Result rental end
ender
Table
Transaction kind Transaction result
B-T01 rental start B-R01 [rental] has been started

B-T02 rental end B-R02 [rental] has been ended


EU-Rent case
DEMO Fact Model (part)
RENTAL

rental rate CAR contracted
MONEY R per day GROUP B-R01 start date
I TIME
the car group of
[rental] is [car group]
contracted
[rental] has
end date
I TIME
been started
Object the contracted pick-up branch
Fact BRANCH of [rental] is [branch] the renter of [rental] is
[person]
PERSON

Diagram the contracted drop-off branch
DRIVER (*)

the driver of [rental] is [person]
of [rental] is [branch]

DRIVING
STARTED LICENSE
RENTAL (*) the driver license of
[person] is [driving
license]


From FM  table definition (spreadsheet)


From table definition  data descriptors
• we built a formula, which
produces NS Expander input from
the table definition (previous
slide)
• this step will become unnecessary
with the “Prime Radiant”


EU-Rent CRUDS-screen (1)


Deriving mockups/screenflow/process
flow from CM/FM/PM/AM*

*“Using Enterprise Ontology as a basis for Requirements for Cross-Organizationally Usable Applications” (Krouwel & Op „t Land, MCIS 2012)

Derivation of mockups/screenflow/
process flow from CM/FM/PM/AM*

*“Using Enterprise Ontology as a basis for Requirements for Cross-Organizationally Usable Applications” (Krouwel & Op „t Land, MCIS 2012)

DEMO-NS prototype EU-Rent
Mockup screen for B-T01 rental start


CRUDS-screen for rentalStart


Uniqueness of a proposition / P-fact
during a transaction / the C-acts
Mirjam request John (rental mediumCar in period 15-20May2012 15/5/2012 10/5/2012 10/5/2012

Trans-
(renter) starter) 14:34 14:40
performer intention addressee P-fact (requested) own intended
(C-act type)
proposition
P-time C-time settlement
time action
Transaction P01-proposition
id transaction carGroup contractedStartDate contractedEndDate … P-time
T01-022 P01-053 T01-023 mediumCar 15May2012 20May2012 15-05-2012 09:00
T01-023 P01-054 T01-023 economy 15May2012 20May2012 15-05-2012 09:00

propo-
T03-005 P01-055 T01-023 economy 15May2012 20May2012 15-05-2012 08:30

sition
C-fact
id proposition intention requester addressee own C-time intended settlement time
C01-00940 P01-053 request Mirjam John 10-05-2012 14:34 10-05-2012 14:40
C01-00941 P01-053 decline John Mirjam 10-05-2012 14:35 10-05-2012 14:45
C01-00944 P01-054 request Mirjam John 10-05-2012 14:40 10-05-2012 14:50
C01-00946 P01-054 promise John Mirjam 10-05-2012 14:42 15-05-2012 10:00
C01-01276 P01-055 state John Mirjam 15-05-2012 08:20 15-05-2012 08:30
C02-01288 P01-055 accept Mirjam John 15-05-2012 08:30 ---

• propositions only can be created in the C-act kinds request and state; all other C-act
kinds may only refer to existing propositions
• a state may refer to an existing proposition, e.g., created during a request or an earlier C-fact
state; a state may also create a new proposition
• a revoke (formerly: “cancel”) never creates a new proposition, it always refers to an
existing C-act, which in its turn refers to a underlying proposition
As solution, we consider to create for the C-fact a separate
component, reusable for all Transaction kinds / Production fact kinds

Applying DEMO’s Distinction axiom:
C-act time?  sentTime, receivedTime
Coordination Human Production
as performer as addressee ability
09:00 social understanding 09:08
ontological action
expose evoke
(decide, judge, manufacture,
commitment commitment
performa observe)

intellectual
09:01 09:07
understanding infological action
express fact educe fact (remember, recall, reproduce,
(formulate) (interpret) deduce, reason, compute,
informa etc.)
significational
09:02 09:05
understanding
perceive datalogical action
utter sentence
sentence (store, transmit, copy,
(speak, write)
(listen, read) destroy, etc.)
09:03 09:04 forma

Fact Model C-world (to be finetuned yet)


Organizational dependencies

• what happens when actor roles are combined/split across functionary
types?
– e.g., request is typed by renter on webpage himself – can this screen now be
reused internally by EU-Rent?
– process flow, mock-up screens, screenflow
• what happens when order of working in workflow is changed?
• how to implement separation of functions?


Conclusions
NS-element connection with DEMO
Data • for P-world: trivially derivable from FM
• for C-world: has to happen once; C-world models to be finetuned
Action • DEMO action rules (AM)  actions in NS: possibly by using an
external Business Rule Engine (BRE)
Workflow • algorithm for state transitions is simple (rq  pm, dc, re(rq))
• how to deal with tacit C-acts from the PM?
• per C-act kind: fixed criterion, per organization, depending on
P-content (amount, type of product, etc.)
Connector • GUI: from CM
• screen fragment per information link +
• standard buttons per C-act + save/cancel +
• P-facts for rq/st +
• standard decision explanations (decision, reason (-code))
• System interface: to be investigated
Trigger • to be investigated


Future research & development
developments
• include coordination as a Normalized Systems standard component
• let end-user start work from a to-do list (DEMO: agenda)
– standardized query, based upon
• the authorization of a user (e.g. “may handle T01-rq”)
• the status of the corresponding C-fact banks (e.g., C01-requested, but not yet –
promised, -declined or -revoked)
• difference between intended settlement time Now (grace-time?)
– refreshable to-do list (push/pull)
• add richer data types: dimension / unity / granularity
– what should be specified in OFD, what in an implementation dependent model?
– domain specific datatypes?

questions/discussion
• the workflows can be highly standardized, using this approach; how
will end-users experience this?

Are you interested in intrinsically durable IT-
systems, derived from models of the essence of an
organization?
• read “Using Enterprise Ontology as a basis for Requirements for Cross-
Organizationally Usable Applications” (Krouwel & Op „t Land, MCIS 2012)
– send me an email, and I will send it to you
• read material on DEMO
– what DEMO is The Deep Structure of Business Processes (Dietz, 2006, Communications of the ACM)
– the DEMO-3 Way of Working , showing the EU-Rent model + how to make it
– how to use DEMO Benefits of Enterprise Ontology in Governing Complex Enterprise Transformations (Op 't Land
& Dietz, EEWC-2012)

• read material on Normalized Systems
– the Wikipedia page on Normalized Systems
– the book “Normalized Systems: Re-creating Information Technology Based on
Laws for Software Evolvability” (Herwig Mannaert & Jan Verelst, Koppa, 2009)
• follow the 5-day course DEMO Professional
– as part of a post-graduate course Enterprise Engineering at INESC/IST (PT)
– as part of the Master in Enterprise & IT Architecture (TU Delft – NL, University
Antwerp – BE)

Any other questions?

Wish you the very best in your efforts for research or its application!

That it may contribute to better and durable solutions
for you and your organizations

Thanks for your attention!
Martin.OptLand@capgemini.com


Implementation Of Ontological Business Transactions Using Demo And The Normalized Systems Approach (Op T Land, Ist, 16 Jul2012) Final

Recomendados

Recomendados

Más contenido relacionado

Similar a Implementation Of Ontological Business Transactions Using Demo And The Normalized Systems Approach (Op T Land, Ist, 16 Jul2012) Final

Similar a Implementation Of Ontological Business Transactions Using Demo And The Normalized Systems Approach (Op T Land, Ist, 16 Jul2012) Final (20)

Último

Último (20)

Implementation Of Ontological Business Transactions Using Demo And The Normalized Systems Approach (Op T Land, Ist, 16 Jul2012) Final