event driven enterprises
Post on 05-Jul-2015
1.040 Views
Preview:
DESCRIPTION
TRANSCRIPT
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: Talk2us@Logical-Inc.com
12COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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.
All Rights Reserved WorldwideBusiness Rules talk
Definition of Event-driven architecture EDA from Wikipedia:
14COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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
15COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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)
16COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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
...
COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
“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
COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
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
COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
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
110COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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.
111COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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.
COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
•Divisions
•Branches
•Departments
•Jobs
•Tasks
Human system groupings: Computer system groupings:•Systems
•Subsystems
•Programs
•Subroutines
•Objects
What was the basis for these historical groupings?
113COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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.
COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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:
COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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.
COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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.
117COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
“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
118COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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
HumanCustomerInterface
ORDERSCREEN
STOCKCHECKINGPROGRAM
INVOICINGPROGRAM
MATERIALSDATABASE
CUSTOMERDATABASE
MATERIALSPICK LIST
MaterialsINVOICE
DeliveredMaterials
RECEPTIONIST
DELIVERYVAN
CUSTOMER
RECEIPT
SUPPLIER
PAYMENT
The Enterprise
119COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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
120COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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
HumanCustomerInterface
ORDERSCREEN
STOCKCHECKINGPROGRAM
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:
121COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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
HumanCustomerInterface
ORDERSCREEN
STOCKCHECKINGPROGRAM
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.
COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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.
123COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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.
COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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!
125COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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…
126COPYRIGHT © 2009, LOGICAL CONCLUSIONS, INC.
All Rights Reserved WorldwideBusiness Rules talk
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:
Brian@Logical-Inc.com
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
top related