event driven enterprises

11COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.

All Rights Reserved WorldwideBusiness Rules talk

Presented by:

Brian Dickinson LCI

for the

Business Rules Forum

Las Vegas NV

Logical Conclusions, Inc.

Business Event Driven

Enterprises Rule!

United States

16001 Burro Drive

Fountain Hills, AZ 85268

Phone: (480) 836-8747

England

18 Honister Avenue

Blackpool, Lancashire

England FY3 9PF

Web: www.Logical-Inc.comEmail: [email protected]

http://www.logical-inc.com/



mailto:[email protected]





Talk Contents:

• The Concept of Events.

• What‟s an Event?

• Events make the World go around.

• What is an Event in the Business World?

• Conceptual view of an Event‟s response as a 3 tiered structure.

• How a Typical Enterprise has fragmented an Event Response.

• Beware the classical implementation groupings in an Enterprise.

• Old/Current/As-Is System Groupings.

• How did we get into this hysterical situation?

• An Enterprise Architecture view.

• “Engineering” an Enterprise.

• “Flavors” of Events.

• Every Enterprise has an “Event Horizon”.

• Undoing the fragmentation of Event partitions/responses.

• Resultant Event-Driven Partitioning across the whole enterprise.

• Event-Driven Partitioning helps eliminate Dead Data.

• Creating Seamless Business Boundaries.

• New Design - Implementing an Event-Driven Partition Team Approach.

• A Real World example of an Implemented Event-Driven Partition.

• Benefits of using Event-Driven Partitioning as an Implementation Structure.

13

The Concept of Events.

There‟s a lot of “alphabet soup” regarding EVENTS in the Information Systems technical literature:

•EDA - Event Driven Architecture

•EOA - Event Oriented Architecture

•CEP - Complex Event Processing

•ESP – Event Stream Processing

(EDA) is a software architecture pattern promoting the production, detection,

consumption of, and reaction to events.

EVENTS

CEP

ESP EOA

The concept of Event processing is finally mainstream after being around for decades but its not just the domain of Information Systems.

We believe becoming an Event Driven organization will set you apart from your competitors, enabling you to be focused on your customers and provide them with quality, timely solutions to their needs.

Also high level Services in Service

Oriented Architecture SOA are equivalent

to the concept of Event processing.

EDA

COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.


Definition of Event-driven architecture EDA from Wikipedia:



What’s an Event?

An Event is: “Anything that happens beyond the area-of-study that requires/produces a response inside the area-of-study". B Dickinson.

Stimulus: “Something that incites into action or exertion.”(Webster’s dictionary)

Each Stimulus arises from an EXTERNAL Event.

Grand Canyon

Example of ENVIRONMENTAL

Stimulus/Response system:

STORM Event – Stimulus RAIN – Response CANYON.

Example of BIOLOGICAL

Stimulus/Response system:

HAMMER BLOW Event – Stimulus PAIN – Response VOICE etc.

Example of ORGANIZATIONAL Stimulus/Response

system:

CUSTOMER NEED Event – Stimulus ORDER –Response – INVOICE & MATERIALS.

A basic premise before we go further - All systems we encounter have a fundamental

characteristic in common – they’re all Stimulus-Response mechanisms.

ANY

SYSTEM



Events make the World go around.

In one process view the world consists of a mass of things (Events) happening through time. We select the ones we are interested in.

Depending on our context of study, these are all valid Events and their Stimuli.

Here are five examples of Events and their Stimuli:

Mouse Click

Isrepresented

as:

Isrepresented

as:

File Cabinent

Time

Database

Human Task

ClockCustomer

Aspect Being Modeled DeMarco Style Symbol Gane/Sarson Style Symbol

Data Flow Data Flow

Process Process

File File

Control Flow Control Flow

* A slash across the flow indicates a stimulating flow.

External Interface External Interface

VerbalContact

Calendar

ElectronicTransfer

WrittenCorrespondence

Computer Task

Isrepresented

as:

Isrepresented

as:

Isrepresented

as:

01001101011001110011010110110010010110010010011100110101

TriggerEvent * *

* *

Pay-Per-Click

COMPUTER TRACKING PROGRAM What‟s on

this link?

Event 1(Internal)

Inter Office Memo/Folder

DEPARTMENT OPERATION

I need to get this to…

Event 2(Internal) Input

Transaction

COMPUTER SYSTEM

Another TranCode 10.

Event 3(Internal)

BUSINESSSYSTEM

I think I‟ll buy…

Customer Order/

RequestEvent 4

(External)

Asteroid Sighting

GLOBAL SYSTEM

I gotta report this!

Event 5(External)



What is an Event in the Business World?

Every enterprise selects a set of Events that it wishes to respond to from the outside world. The enterprise has no control over these EXTERNAL Customer Events, it simply responds to the arrival of the stimuli from the Events.

Each external need to which we respond is called an “Event.”

BANKAIRLINE

BUSINESS

Divisions, Departments, Offices, etc.

Files, Databases

Computer Systems, Programs

Info. Desk

Staff/Mgmt.

An Event Partition.

Customer

Order/Request

Response

In the business world the most important Events are initiated by whomever the enterprise calls its “Customer.”

GOVERNMENT

I need to go to…

I need some cash.

Its tax time.

I need to buy…

17

Forming an Enterprise’s Core Business

We can conceptually view an enterprise‟s response to an Event as a 3 tiered structure. First, each “Business” Event forms its own enterprise Business Core.

The customer imagines a quality

enterprise will satisfy their needs

seamlessly. After all, the enterprise

depends on its customers to stay in

business.

“Let‟s specialize in

providing products

and services, to our

customers, in the

area of...”

Most enterprises take on a limited set of

Events which they refer to as their core

competency.

One Business Core

Cu

sto

me

r Wa

nts

To

...



“We need you to …”

Mission

Selected

Events

Business

Analysis

Systems Design/

Implementation

Customers

18

Forming the Event-Driven Business Policy Layer

Each enterprise creates its own Business Policy (rules for processing, data, and controls) associated with each Event. This forms the Business Policy Layer surrounding the Business Core.

DATA (Nouns)

associated

with the Event

PROCESSING

(Verbs)

associated

with the Event

This Business Policy Layer is where

each enterprise gets to really

distinguish itself from its competition.

The detailed processing, data and

controls specifies WHAT is activated

to satisfy the Event.

Specific Business

Policy Layer

One Business Core

_________________________________

IF REQ. DATE = 1 MONTH OLD

Send SUPPLIER NOTICE

Add to Overdue REQS.

ELSE

IF REQ. DATE > 7 Days

Add REQ. ID to Late REQS.

REQUISITION =

REQUISITION ID +

REQUISITION DATE +

(REQUISITION DELIVERY DATE) +

{MATERIAL ID +

REQUISITION MATERIAL QUANTITY}

SUPPLIER ID = DATA ELEMENT

Business Rules talk


All Rights Reserved Worldwide

Note: There may be some rules that are dictated by

entities beyond our enterprise, e.g. government laws and

regulations of affiliated organizations.

Mission

Selected

Events

Business

Analysis

Systems Design/

Implementation

Data Definition:

Process Specification:

19

Forming the Event-Driven Technology/Customer Interface Layer

To implement the Business Policy in the real world the enterprise adds a Technology/ Customer Interface Layer for the Event.

The Technology Layer consists of

human and/or computer devices

along with their support systems

designed to interact with the

customer and to deliver the goods

or services requested.

Our Customers

Interact with this Layer.

Technology

Layer

Specific Business

Policy Layer

One Business Core

Business Rules talk


All Rights Reserved Worldwide

Procedures Manual/Computer Code

Production Budgets, Plans, &

Schedules

The Technology Layer

specifies HOW the Event is

implemented in the real

world.

Mission

Selected

Events

Business

Analysis

Systems Design/

Implementation



It‟s Technology Layer identifies

“How” the policy is implemented.

It‟s Policy Layer identifies “What” Business logic is initiated by the Event.

Each Event forms One Business Core

Conceptual view of an Event’s response as a 3 tiered structure.

Bu

siness E

vent

Specific

Business

Processing,

Data and controlsProduction Budgets, Plans, & Schedules

Procedures Manual/Computer Code

Databases/Files

Technology to make the Business Policy work in production.

Customers interface with our business via this layer.

Captured information

One structure per

Event E.G.

•Cust. Deposit

•Cust. Withdraw

•Cust. Transfer

Prob. unique to Org.

Not usually unique to an Org.

The Event Identification and its Stimulus (from the Event List).

The detailedData, Processesand ControlsAssociated with the Event.

The Technology

used to

Implement the

Event response.



How a Typical Enterprise has fragmented an Event’s Implementation.

Unfortunately, the typical enterprise has not maintained the “cohesiveness” of their Event responses and have allowed old departmental structures and haphazard systems development efforts to fragment a response to their customers.

Order FulfillmentDepartment/

System

SalesDepartment/

System

AccountsDepartment/

System

Stock ControlDepartment/

System

ReportingSystem

CUSTOMERCUSTOMER

“Look how they‟ve fragmented my

business...”

Founder.

Fragmenting an Event Response in this way is known as “Stove Pipe” partitioning.

One Cohesive Event

Response

? ?

112

Beware the classical implementation groupings in an Enterprise.

Its all too common to see groupings of processes, data and controls into historical, industrial age patterns.



•Divisions

•Branches

•Departments

•Jobs

•Tasks

Human system groupings: Computer system groupings:•Systems

•Subsystems

•Programs

•Subroutines

•Objects

What was the basis for these historical groupings?



Old/Current/As-Is System Groupings.

Obviously the original groupings were based on human skills. E.G. Accountants in Accounting, Sales people in Sales Dept. But note: Historical groupings will perpetuate themselves (unless actively changed) and can become “hysterical” groupings, for example:

Replace the above example with:ORDER ENTRY, NEW ACCOUNTS , SCHEDULING, STOCK CONTROL, ACCOUNTS RECEIVABLE,

ACCOUNTS PAYABLE, GENERAL LEDGER, SHIPPING and BILLING SYSTEMS etc.(Not to mention Management Structures.)

So many Computer systems followed the same grouping as the old Manual systems.

Manual Accounts Dept.Computer Batch Accounts System

Computer On-Line Accounts System

Believe me, I can do more.

I have an accounting

degree.

I seem to know

accounting.

Management Timeline goals: “Automate this!” “Put this On-line!” “Put this on the Internet!”

Lead to… Lead to… Lead to…

“Error - Not on this server.”

Internet enabled Accounts System…

(I Can Add & Subtract)

114

How did we get into this hysterical situation?

The problem of perpetuating historical groupings/partitions stems from not recognizing that humans, just like computers, are an aspect of technology –

i.e. an aspect of implementation. Implementation issues always get in the way of a good Analysis of enterprises/departments/old systems etc.



Information Systems (IS/IT) folks should build systems using Methodologies which recommend analyzing and seeing through these old designs.

Formal methods such as Process Analysis, Information Analysis, Object Analysis produce deliverables (e.g. models) partitioned by specific views (e.g. As Is, To Be etc).

We should not use historical groupings for new specifications within an Enterprise Architecture.

Unfortunately many old Information Systems people as well as Packaged Software Vendors perpetuated old boundaries when they built and “sold” systems to department managers.

Accounts Dept.

Using EVENTS to drive business partitioning allows us to see through these old/outdated boundaries.

“They „re promoting me and giving me a budget.”

“I‟m calling the Information Systems Department for help.”

Bill Head

115

An Enterprise Architecture view.

An Enterprise Architecture is a representation of „How you view your Business‟. It utilizes distinct major specifications in order to capture all aspects of the enterprise.

•Business Process Architecture

A Process Model

•Business Information Architecture

An Information Model

•Human Implementation Architecture

A Control Hierarchy

•Systems Application Architecture

Software structure Model

•Technology Architecture

Hardware structure Model.Each specification has it’s own sub-groupings and components.

There are many ways to specify an enterprise:



Each one of these views can, and should, be based on the enterprise‟s Events.

116

“Engineering” an Enterprise.

When we take a disciplined approach to specifying an enterprise we need to capture and define many individual components within the major specifications.



Functional Processes/ Procedures

(e.g. Verify Customer Account)

Data Elements(e.g. Customer Name) Controls

(e.g. At End-Of-Year …)

Relationships(e.g. Customer BUYS Product)

Process Groupings(e.g. Process Customer Order)

Data Groupings(e.g. Customer Order)

State/Transitions(e.g. Wait state until card

inserted then…)

Objects/Methods(e.g. File can:

New/Open/Delete…)

Captured information(Metadata – Data about Data)

Defining these components is important but how we organize and group them together is even more important.



“Flavors” of Events.

We should structure our enterprise around Events but it‟s important to differentiate between the kinds of Events that occur in and around an enterprise.

Strategic Events – those that dictate the contents of the enterprise‟s policy. (These form the Meta Model.)

System Events – these are “invented” at design time to support the implementation of the above Events.

1. Business Events – those to which an enterprise wishes to respond. These fulfill the enterprise‟s mission. They always originate at who or what is called a Customer.

2. Dependent Events – those to which an enterprise responds to be able to satisfy its Business Events. They usually come from vendors to the enterprise and are created when part of a Business Event is outsourced.

3. Regulatory Events – those to which an enterprise is required to respond. They come from a government or business regulatory agency.

The most important for Business

Process Improvement.

Capturing these three kinds of

Events enables “data conservation”

(No Dead or Unnecessary stored

data) across the whole enterprise.

These are usually internal and always related to Human and computer

system issues.

These are the responsibility of the

strategic policy makers.

SpokenOrder

InputOrder

ElectronicOrder

CheckedOrder

Stock PickList

Invoice

Cust.IDs

CheckCust.

CUSTOMER

CUSTOMER

SHIPPINGCLERK

HumanCustomerInterface

ORDERSCREEN

STOCKCHECKINGPROGRAM

INVOICINGPROGRAM

MATERIALSDATABASE

CUSTOMERDATABASE

MATERIALSPICK LIST

MaterialsINVOICE

DeliveredMaterials

RECEPTIONIST

DELIVERYVAN



Every Enterprise has an “Event Horizon”.

At a high level we can conceptually view and model an enterprise as a „Black Box‟ that responds to a set of external Events.

We call this view an Enterprise Context Diagram.

When studying an enterprise we can use this Context Diagram and its Event stimuli as a guide to further analyze and partition the enterprise‟s operations, as well as the specifications within the Enterprise Architecture.

Event List:

Business Event 1 :Customer wants to Order our Products.

Business Event 2 :Customer wants to pay our Invoice.

Dependent Event 1 :

Supplier Delivers Material.

Regulatory Event 1 :Tax Deadline Arrives.

Business Event 3 :Dividend Period Arrives.

CUSTOMER

OWNER

CALENDAR

GOVERNMENTSUPPLIER

CUSTOMER

PAYMENT

CUSTOMER ORDER

ORDERED

PRODUCT&

INVOICE

MATERIAL

DELIVERY

TAX

REPORTS

PROFIT &

LOSS

STATEMENT

DIVIDEND

PERIOD

TAX

DEADLINE

Sample Enterprise Event Context Diagram and Event List.

The Enterprise Event Horizon

SpokenOrder

InputOrder

ElectronicOrder

CheckedOrder

Stock PickList

Invoice

Cust.IDs

CheckCust.

CUSTOMER

CUSTOMER

SHIPPINGCLERK


ORDERSCREEN


INVOICINGPROGRAM

MATERIALSDATABASE

CUSTOMERDATABASE

MATERIALSPICK LIST

MaterialsINVOICE

DeliveredMaterials

RECEPTIONIST

DELIVERYVAN

CUSTOMER

RECEIPT

SUPPLIER

PAYMENT

The Enterprise



Undoing the fragmentation of Event partitions/responses.

To produce a view/model that is not corrupted by any old designs we should concentrate on capturing details of six components for each Event response.

This view shows the enterprise‟s complete reaction to an Event.

Every Event will have a Source, Stimulus and associated Processing, however Stored Memory,

outgoing Response(s) and Recipient(s) are optional.

These six Event components form a functional, EVENT-DRIVEN, partitioned model–

one level below the Enterprise Context Diagram.

The Memory (Files) used to process the Event.

The Recipient of the Response to

the Event.

Who or what.The Responsegenerated by the

Event.

Data or control.

The Processing initiated by the Event

Stimulus.

The business policy.

The Source(initiator) of the

Event.

Who or what.

The Stimulusresulting from the

Event.

Data or control.Process Order:

For each MATERIAL IDIf MATERIAL AVAILABLEThen Reduce Inventory By

MATERIAL QUANTITYElse

Create BACK ORDER…

Thing

Thing

ThingThing

Thing

Thing

Thing

Thing

Thing



Resultant Event-Driven Partitioning across the whole enterprise.

An Event Partition consists of an End-To-End, set of components required to COMPLETELY satisfy one need of a Customer. (A Definition.)

Similar to - Swim lanes/Value Chains/Services.

We can break down complex Event Partitions into more detail.

BUSINESS EVENT

STIMULUS

BUSINESS EVENT

STIMULUS

RESPONSE

RESPONSE

RESPONSE

RESPONSE

RESPONSE

RESPONSE

BUSINESS EVENT

STIMULUS

REGULATORY EVENT

CONTROL STIMULUS

Note: Files are only needed at the intersection between Events. Therefore Event-Driven Partitions can be implemented as separate systems/projects.

SpokenOrder

InputOrder

ElectronicOrder

CheckedOrder

Stock PickList

Invoice

Cust.IDs

CheckCust.

CUSTOMER

CUSTOMER

SHIPPINGCLERK


ORDERSCREEN


INVOICINGPROGRAM

MATERIALSDATABASE

CUSTOMERDATABASE

MATERIALSPICK LIST

MaterialsINVOICE

DeliveredMaterials

RECEPTIONIST

DELIVERYVAN

Essential File

Essential File

Essential File

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Year End

A sample lower level Process Model showing four Event Partitions:



Old Reporting

Old Accounts

Old Order Entry

Event-Driven Partitioning helps eliminate Dead Data.

We can easily recognize “Dead/Unnecessary” data and files when the Event-Driven Partitioned model is overlaid with the old design structures. We can also see how

unnecessary files slow down the response to a Customer.

BUSINESS EVENT

STIMULUS

BUSINESS EVENT

STIMULUS

RESPONSE

RESPONSE

RESPONSE

RESPONSE

RESPONSE

RESPONSE

BUSINESS EVENT

STIMULUS

REGULATORY EVENT

CONTROL STIMULUS

This overlay with a typical design indicates that more system boundaries will result in more files and an increase in potential errors and inefficiencies.

SpokenOrder

InputOrder

ElectronicOrder

CheckedOrder

Stock PickList

Invoice

Cust.IDs

CheckCust.

CUSTOMER

CUSTOMER

SHIPPINGCLERK


ORDERSCREEN


INVOICINGPROGRAM

MATERIALSDATABASE

CUSTOMERDATABASE

MATERIALSPICK LIST

MaterialsINVOICE

DeliveredMaterials

RECEPTIONIST

DELIVERYVAN

Essential File

Essential File

Essential File

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Design

File

Design

File

Design

File

Design

File

Design

File

Design

File

Design

File

Design

File

Design

File

Old Stock Control

Year End

122

This model also shows a more “natural” view of the essential business processing.

Adapting Newton‟s First Law of Motion: The customer‟s impetus (like a body in motion) wants to stay in motion until impeded by some resistance (i.e., an unnatural boundary). Its original driving force (the customer stimulus) gets lost when dissipated through a series of false partitions.



Creating Seamless Business Boundaries.

By separating and modeling each Event-Driven Partition we can see the minimum collection of components needed to fulfill a customer‟s need.

Originating

Stimulus

One un-fragmented Event Partition (Process Model).

Was part of old Order

Entry System

Was part of old

Accounting System

Was part of old Stock Control System

Was part of old Order

Fulfillment System

No old “design” File delays here!

DATA

CUSTOMER

Process

Process

ProcessCUSTOMER

Process

Process

DATA

DATA

DATA

Essential File

Process

Note: As much as possible use data

stimuli to detect the processing‟s true

flow.



New Design - Implementing an Event-Driven Partition Team Approach.

We can use each Event-Driven Partition as a “natural” structure for implementation of new systems in our enterprise.

Resulting in true “FUNCTIONAL” units (Manual and/or Computer systems).

The Business Event implementation “Team” can:

consist of one individual (with many “hats”) with one computer program/system

be an empowered team of individuals with many reusable computer programs

take on one or more implemented Event Partitions - depending on the size and volume of an Event Partition

be replicated for voluminous Events.

Business Event Program/Objects

ID: Customer wants to purchase our Materials.

Implementation View:

A Business Event Implementation

Team

Team 1 Metrics: …

Team 2 metrics: …

AND

•No typical errors between old departments or computer systems

•fastest response to the customer

•easier maintenance/modification

124

A Real World example of an Implemented Event-Driven Partition.

This “instance” of an Event-Driven Partition was implemented in 7 minutes with an empowered Human (carbon unit) and Computer (silicon unit) based team.



Process:

Arrive - Find part - Fit part... Invoice - Accept payment - Leave.

Silicon based unit

Carbon based unit

Another Silicon based unit

Broken refrigerator.

Satisfied Customer is taking the photos!



Benefits of using Event-Driven Partitioning as an Implementation Structure.

Implementing Whole Event-Driven Partitions may help us realize orders of magnitude savings of time and money over our current systems and makes us focus on being truly responsive to our customers.

An implementation example of a whole Business Event Compartment:

Response measured in Seconds/Minutes/Hours?

Minutes/Hours

Delay here of Mins./Hours/Days?

Secs./Mins.

An implementation example of a “fragmented” Event partition:

CUSTOMER

Minutes/Hours

CUSTOMER

Response measured in ”Business Days” or even Weeks.

Delay here of Secs./Mins./Hours?

Secs./Mins.

Delay here of Mins./Hours/Days?

Computer System A

Computer System B

Minutes/Hours Secs./Mins.

Computer System

An Event Driven Implementation is:

•The most responsive to your customer

•Easier to maintain

•Easiest to Modify

•Even easier to build…



Presentation Created by:

Brian Dickinson

For questions on this presentation or for information on Seminars and Consulting on

Event-Driven Enterprises

and

Business Process Management/Improvement

Please email me at:

[email protected]

Or

Call (480) 836-8747

Logical Conclusions, Inc.

United States

16001 Burro Drive

Fountain Hills, AZ 85268

Phone: (480) 836-8747

England

18 Honister Avenue

Blackpool, Lancashire

England FY3 9PFWeb: www.Logical-Inc.com





