Implementation Of Ontological Business Transactions Using Demo And The Normalized Systems Approach...

Implementation of Ontological Business Transactions using DEMO

and the Normalized Systems approach

Prof.dr. Martin Op 't LandInnovation 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ÊNCIA16 DE JULHO, 18h00, Anfiteatro PA-3. IST, CAMPUS DA ALAMEDA, LISBOA

©2012 Martin Op 't Land

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

July 16th, 2012Implementation of Ontological Business Transactions using DEMO and the Normalized Systems approach 2

Today we want to show you a sneak preview on work-in-progress


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



July 16th, 2012

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 Ontologyto the Splitting and Allying of Enterprises

– Summarized for managers in Instrument forfast and effective splitting of organizations (NL)

• first book @ Springer (2009)

– Enterprise Architecture: Creating Value by Informed Governance

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

I like to advance enterprise agility by connecting organization granularity with ICT granularity

http://repository.tudelft.nl/view/ir/uuid:0edd0472-39df-4296-b692-e9916e79fb1e




http://repository.tudelft.nl/view/ir/uuid:139c7255-226c-49c0-a6e8-31eebf49d3b7



http://repository.tudelft.nl/view/ir/uuid:6e42101e-9b37-42a8-985b-54aeb09e829c

http://www.springer.com/business/business+information+systems/book/978-3-540-85231-5

http://www.ciao.tudelft.nl/


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.

• Transaction Axiom– C-acts and P-acts always occur in particular patterns (OER)

• Composition Axiom– Transactions (which bring about new facts in reality)

are related to each other in one of two possible ways:• a transaction is enclosed in another transaction;

• 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)


E-phase

O-phase

R-phasecustomer producer

fact stated

fact accepted

fact promised

fact produced

request

desired new fact

fact requested

promise

stateaccept


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

T1

productioncoordination

here productionfacts are created

here coordinationfacts are created

Kinds of coordination acts

success “problems” discourse

request quit revoke

promise decline refuse

state stop allow

accept reject

July 16th, 2012

7

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


DEMO’s distinction axiom

Coordination Humanability

Production

as performer as addressee

exposecommitment

evokecommitment

performa

ontological action (decide, judge, manufacture,

observe)

express fact(formulate)

educe fact(interpret)

informa

infological action (remember, recall, reproduce,

deduce, reason, compute, etc.)

utter sentence(speak, write)

perceive sentence

(listen, read)forma

datalogical action (store, transmit, copy,

destroy, etc.)




A DEMO model of a B-organization consists of 4 aspect models

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

SMPM

AM

CM

B-organization

I-organization

D-organization

State Model

Action Model

Process Model

Construction Model A07

actor A07

A01

actor A01

A00

actor A00

T07

transaction T07

T01

transaction T01

S01: S01 system border

A01 is executor of T01A00 is initiator of T01

Actor A07inspects facts fromtransactions T01


Several real-life cases suggest significant benefits of DEMO in governing transformations

where Effort Return

ROOD 5 weeks for CM, ½ day GDS

well-underpinned re-allocation of responsibilities (5,000)

VISI standard DEMO-training

rapid design of civil construction 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 ½ yr

application portfolio rationalization proposal, 49% saved (130 apps, used by 300 staff in 6 regions)

RWS-Deltares several 10s of man-days

organization-split proposal + items for contracting

AFKL Cargo 65 man-days in 6 weeks

neutral language, agreement upon design and migration issues



Example: EU-Rent, modeled in DEMO (CM)


B-CA03

payer

B-A01

rentalstarter

rental start

B-A02

rentalender

B-T01

car pick-up

B-CA02

driver

car drop-off

B-CA01

renter

rental payment

B-T05

EU-Rent

EU-Rentdata

B-T03

B-T04

rental end

B-T02

TransactionResultTable

Transaction kind Transaction result

B-T01 rental start

B-T02 rental end

B-T03 car pick-up

B-T04 car drop-off

B-T05 rental payment

B-R01 [rental] has been started

B-R02 [rental] has been ended

B-R03 the car of [rental] has been picked-up

B-R04 the car of [rental] has been dropped-off

B-R05 [rental] has been paid

ConstructionModel

EU-Rentdata

personaldata

B-APB01

B-APB02

B-APB01


Content

• Normalized Systems (NS) = systems that can be changed without combinatorial effects

–one type of anticipated change will only propagate in one module

–a given maintenance action on an NS-system costs (even formally) proven exactly as much impact now, or two years later (when the NS-system is, say, five times as large and complex)

• NS theory and tools developed by University of Antwerp (UA)

Benefits

• productivity improvement in development

– factor 2-3 has been proven realistic

• maintenance improvement even better, because NS = top quality software


What is Normalized Systems (NS)?

“Our insight in what software quality

comprises is changed to such an extent

that we can no longer imagine to

develop good software without

Normalized Systems.” (5 well-seasoned

developers of Capgemini, 2011)

http://en.wikipedia.org/wiki/Normalized_Systems


SoC: Separation of Concerns

DVT: Data Version Transparency

AVT: Action Version Transparency

SoS: Separation of State

Data

Action

Workflow

Connector

Trigger

26

NS Elements v1.1

Structuur StandaardFunctionaliteit - element caching-deep link details

- tree structuren

- grafische voorstellingen met

iconen

- mekaar aansturende picklists - import/export naar xml en csv- taal en statusrepresentatie

+

Encaps

Remote

Access

Persist

Service

…

…

X-cutting concerns

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

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


4 Principles 5 Elements

GUI

http://www.koppa.be/?page_id=11


EU-Rent caseDEMO Construction Model (part)


OrganizationConstructionDiagram

TransactionResultTable

Transaction kind Transaction result

B-T01 rental start B-R01 [rental] has been started

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

B-A01

rental

starter rental start

B-A02

rental

ender

B-T01 B-CA01

renter

EU-Rent

rental end

B-T02


EU-Rent caseDEMO Fact Model (part)


the contracted pick-up branchof [rental] is [branch]

RENTAL

the renter of [rental] is [person]

PERSON

STARTEDRENTAL (*)

BRANCH

[rental] hasbeen started

DRIVER (*)

Icontractedstart dateB-R01

the driver of [rental] is [person]the contracted drop-off branchof [rental] is [branch]

TIME

Icontractedend date

TIME

the car group of[rental] is [car group]

CARGROUP

rental rateper dayRMONEY

ObjectFactDiagram

DRIVINGLICENSE

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

• 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 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

Trans-action

propo-sition

C-fact

intention(C-act type)

addressee P-fact

proposition

Mirjam (renter)

performer (requested)P-time

ownC-time

intendedsettlement

time

10/5/201214:34

10/5/201214:40

request John (rental starter)

mediumCar in period 15-20May2012 15/5/2012

C-factid 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 ---

P01-proposition

id transaction carGroup contractedStartDate contractedEndDate … P-time

P01-053 T01-023 mediumCar 15May2012 20May2012 15-05-2012 09:00

P01-054 T01-023 economy 15May2012 20May2012 15-05-2012 09:00

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

Transaction

T01-022

T01-023

T03-005


Applying DEMO’s Distinction axiom:

C-act time? sentTime, receivedTime


Coordination Humanability

Production

as performer as addressee

exposecommitment

evokecommitment

performa

ontological action (decide, judge, manufacture,

observe)

express fact(formulate)

educe fact(interpret)

informa

infological action (remember, recall, reproduce,

deduce, reason, compute, etc.)

utter sentence(speak, write)

perceive sentence

(listen, read)forma

datalogical action (store, transmit, copy,

destroy, etc.)

social understanding

intellectualunderstanding

significationalunderstanding

09:00 09:08

09:0509:02

09:01 09:07

09:03 09:04


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)


http://www.sysedv.tu-berlin.de/Homepage/SYSEDV.nsf/0/BC7C3B06F298EF9DC12576540038F1A9/$FILE/dietz_04. The Deep Structure Of Business Processes_BPR.pdf




http://www.demo.nl/publications/doc_download/122-demo-3-way-of-working




http://repository.tudelft.nl/view/ir/uuid:18d90cf6-fddc-48ae-8101-e9eda186a72c








http://www.koppa.be/?page_id=11

http://www.antwerpmanagementschool.be/en/our-programs/masters-for-professionals/executive-master-of-enterprise-it-architecture-(meita).aspx

http://www.antwerpmanagementschool.be/en/our-programs/masters-for-professionals/executive-master-of-enterprise-it-architecture-(meita).aspx


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!

[email protected]


mailto:[email protected]

Implementation Of Ontological Business Transactions Using Demo And The Normalized Systems Approach...

Business

Transcript of Implementation Of Ontological Business Transactions Using Demo And The Normalized Systems Approach...