This document discusses application architecture and provides examples of how to properly structure applications using rules, processes, and data. The key points are: 1) Rules should represent business logic and processes should manage workflow and status. Data should not drive processes or contain logic. 2) Case studies demonstrate how to separate concerns - using a rule engine for calculations and decisions, a process engine for workflows, and a database for data storage. 3) Integrating systems through shared memory (e.g. JBoss Data Grid) and rules can enable high-performance big data processing and integration across different business units and systems.

1. Application Architecture
-‐‑‒ Data, Process, Rule -‐‑‒
Red Hat Japan
JBoss Service
Senior Solution Architect, BRMS Evangelist
Masahiko Umeno

2. ARCHITECTURE
Copyright © 2014 Red Hat K.K.
2

3. ARCHITECTURE
Copyright © 2014 Red Hat K.K.
3

4. l “IT” is a tool for Business, and Business is a “creature”.
l Business Agility
l Small but continuous changes keep occurring. Not a big
change, revolution.
l Additions and changes in a system happen as business
requests them.
l “Exception” are just inevitable.
l IT (business applications) does not catch up with a
speed of business progress, and/or requires major costs
to do so.
Well, aren't there any problems with
application architecture?
Why Architecture matters?
Copyright © 2014 Red Hat K.K.
4

5. What causes bad maintainability?
Copyright © 2014 Red Hat K.K.
5
• amount = null and authCode =0 or 99 → START
• amount >= 0 and ApplicantName start with “J” → Waiting for
approval at Domestic
• amount >= 0 and 1stApproval = 8 or 2ndApproval = 8 or 9, and
SKU does not start with “A”, “B”,…, “K” → Required BU approval
• Want to do
→ amount = 100, Applicant start with “S”, 1stApproval = 7. Status?
→ Want to make a new status…
Example
l "Status as a combination of data”
l Processes should decide status management, not the
opposite.
l Tightly coupled data and process
l Once unexpected data is submitted, the task will be lost.

6. What causes bad maintainability?
Copyright © 2014 Red Hat K.K.
6
l "Status as a combination of data”
l Processes should decide status management, not the
opposite.
l Tightly coupled data and process
l Once unexpected data is submitted, the task will be lost.
l Complex data diagram, like a jungle.
l Processes should be simple.
l A lot of branching is made based on the data
l If a process is determined by data, then it is a good idea to
use rule engine for handling them and keeping a process
itself simple.

7. What causes bad maintainability?
Copyright © 2014 Red Hat K.K.
7
l "Status as a combination of data”
l Processes should decide status management, not the
opposite.
l Tightly coupled data and process
l Once unexpected data is submitted, the task will be lost.
l Complex data diagram, like a jungle.
l Processes should be simple.
l A lot of branching is made based on the data
l If a process is determined by data, then it is a good idea to
use rule engine for handling them and keeping a process
itself simple.
l A rule named the "Master”
l Referring the master DB from a logic.
l Unless users maintain the master table well, wrong results
can be sent for a long period.
l If changes cannot be made or maintained in the master
table, then it needs to be described as a program logic.
Regulation
Master
Accessories
Master
Color
Master
Parts
Master
Calc
Master

8. The most IMPORTANT part in the architecture
Copyright © 2014 Red Hat K.K.
8
Process
Rule Data
View
Auth
Integr
ation
Mail
70〜～80%

9. The most IMPORTANT part of the architecture
Copyright © 2014 Red Hat K.K.
9
画⾯面
認証 連携
Mail
Process
Rule Data
70〜～80%

10. Copyright © 2014 Red Hat K.K.
10
I had a question on a simple thing.
What
is
SOA?
Why
are
there
no
success
stories
with
it?

11. What is “SOA”?
Copyright © 2014 Red Hat K.K.
11
Service Bus
Sales Logistics
Manufac
ture
Logistics Financial
Sales Customer Logistics Financial Manu
Est Ord New Inspec Claim withdImport Shipping Cost Quality
View
BPM
App
DB
ESB

12. Copyright © 2014 Red Hat K.K.
12
Is this
Architecture
efficient?
Doubt

13. l Process (BPM)
l Records a status of a person who works responsibly.
l Decides a processing order based on a defined procedure.
l Is NOT a part to describe a system connectivity, or logics.
l Data (DB)
l Stores the transaction data.
l Keep a record of status.
l Is NOT a part to store business logic.
l Business logics should NOT be written with stored
procedures.
l Rule (BRMS)
l IS a part to check, compare, calculate, or deduct.
l IS a key to maintain and enhance business agility amid
changes in business.
Three Principles : Role and Responsibility
Copyright © 2014 Red Hat K.K.
13

14. RULE AND PROCESS
Case Study
Copyright © 2014 Red Hat K.K.
14

15. Case Study1
Copyright © 2014 Red Hat K.K.
15
Rule
Salary
Learning
Status
BPM
Process Start
Check Dept
Candidate Chk
Reason
Aptitude
Training Check
Cost
Employee
Status
BPM
Waiting Appr
StatusBPM
Task List
HR
Appr. Start
Get data
using key as
Emp. No.
Send All of
the data
Result
Start
Process
GetData
Rule
Store
NextTask
HR
BPM
Approval Status
List
Data
Next
Fetch a data or store a data
to DB. Do NOT use DB as
decision. Also do NOT handle
any exception in the SQL.
データの確認事項などは全て
ルールエンジン側で⾏行行い、判定
結果を出⼒力力する。
Sore data to HR DB.
Input
List of
Dept.
Comp. Input
Appr. End
Tire Manufacturing Company
• Rebuild HR system
• Many Process, Many subsidiary

16. Copyright © 2014 Red Hat K.K.
16
IMPORTANT
Do NOT refer DB from Rule Engine!!

17. Copyright © 2014 Red Hat K.K. | Confidential
Rule
Authoring
BRMS
Rule
Mgmt
Simulation
Servlet Application
DB
Decision
Service
Result
DB
Process
Service
Process
Service
① ②
③
④
⑤
⑥
⑦
⑧⑨
⑩
⑪
Case Study 2
17
Steel Company
• Cost Calculation of Recipes
• Handled by Excel, Many Recipes
Excel to BRMS

18. Do not use the BPM as Service Orchestrations!!
Copyright © 2014 Red Hat K.K. | Confidential
Store DB
Other System
(MQ)
Retrieve DB
Calculation
(BRMS)
Applicant Approver Purchasing
Vertical
“Service Orchestration”
Click!! Click!! Click!!
Process Mgmt
(BPM)
Biz Process
next Next
Notice by eMail
(Message)
18
Horizontal
“Business Process”
Check
(BRMS)
Record Who, When did this
task with responsibility.
Assign the task to next
approver.
Service

19. RULE AND DATA
Case Study
Copyright © 2014 Red Hat K.K.
19

20. Copyright © 2014 Red Hat K.K. | Confidential
Shell Script
Read Data
Matching
Store DB
Query
Rule Check Relations
between Signal
Store DB
Sort
Case Study3
20
Contract
Signal
Data
Summary
Data
To JOBID 570
JOBID 560
StartUp
Batch Program Nightly
Security Company
• Checking 200,000,000 trn/day
• Overload at Host, Cobol to BRMS
File
COBOL to BRMS

21. Copyright © 2014 Red Hat K.K. | Confidential
Shell Script
Read Data
Matching
Store
Data
Map
Reduce
Sort
File out
Case Study3
21
Rule
Engine
Hokkaido
Tokyo Osaka
User JDG as “Ultra high speed shared memory”.
[1] user a client mode because contract data
want to share with the other area.
[2] Library mode. Rule engine is called by JDG,
create summary (calculated) data.
[3] output a data from JDG.
Contract
This is the high-‐‑‒speed and scalable architecture
using shared memory and rule engine.
To use JGD, data
can handle as
KVS. Import,
Map Reduce,
Output.
JDG
Loop
Pro: Enable high speed process
Con: Require memory and CPU
JDG
[1]
[2]
[3]
StartUp
COBOL to BRMS

22. DATA INTEGRATION
Copyright © 2014 Red Hat K.K.
22

23. BatchRealtime
The role of data Integration
Copyright © 2014 Red Hat K.K.
23
Screening
Transaction
Data
Customer
Data
SAP
MS-‐‑‒
Access
Data Virtualization
JDBC
ESB
NetWeaver
IDOC
Request/Reply with
REST
MS-‐‑‒
Excel
Virtual Data View
Protocol Conversion
Message Conversion
MQ
Message Service
JDBC
Nightly
Batch MS-‐‑‒Exchange
Publish / Subscribe
P2P
HULFT FTP
Mobile
Not a Service integration.
ODBCJDBC

24. CONCLUSION
Copyright © 2014 Red Hat K.K.
24

25. What is “SOA”?
Copyright © 2014 Red Hat K.K.
25
Service Bus
Sales Logistics
Manufac
ture
Logistics Financial
Sales Customer Logistics Financial Manu
Est Ord New Inspec Claim withdImport Shipping Cost Quality
View
BPM
App
DB
ESB

26. Best Practice Architecture
Copyright © 2014 Red Hat K.K.
26
Sales Logistics
Manufac
ture
Logistics Finance
Service Bus （Protocol/Message conversion between App and Service if need）
Data
Service
Process
Service
Decision
Service
Message
Service
Other
System
Estm Order
Claim Collect
View
APP
ESB
Service
DB
Process Data Data ProcessEstim
Process Data Data ProcessOrder
Process Data Data ProcessClaim
Estm Order
Claim Collect
Decision
Decision
Decision
Micro Services
Estm Order
Claim Collect

27. Red Hat Products
Copyright © 2014 Red Hat K.K.
27
営業部 物流流部 製造部 物流流部 経理理部
サービスバス
データ
サービス
プロセス
サービス
ディシジョン
サービス
メッセージ
サービス 他システム
⾒見見積 受注
請求 回収
View
APP
ESB
Service
DB
プロセス データ データ プロセス⾒見見積
プロセス データ データ プロセス受注
プロセス データ データ プロセス請求
⾒見見積 受注
請求 回収
ディシ
ジョン
ディシ
ジョン
ディシ
ジョン
Fuse Service Works
JBoss Fuse
JBoss Data
Grid
JBoss
Data Virtuali-‐‑‒
zation
JBoss
BPM
Suite
JBoss
BRMS
JBoss
A-‐‑‒MQ
RHEL
KVM
Storage
Open Stack
JBoss EAP Feed Henry (Mobile)

28. Solution Approach
Copyright © 2014 Red Hat K.K. | Confidential
28
# Action Input How Outcome
1 Requirement
Definition
• Request from
Business User / IT
User
• Hearing • Requirement
Definition
• Challenge of
Business and IT
2 Fit and Gap • Requirement Doc.
• Red Hat Best Practice
• Arrangement
• Break Down
• Mapping
• Detail
• System Requirement
3 Propose • Challenge of Biz & IT
• System Requirement
Doc.
• PoC Proposal
4 PoC • System Req.
• PoC Proposal
• Design
• Build
• Evaluate
• PoC Report
5 Estimate
Project
System Req. • Role & Responsibility
• SOW
• Org Chart
• Project Price
Any project requires this procedure in this order.

29. Copyright © 2014 Red Hat K.K.
29
Thank you.
謝謝。
감사합니다.
ありがとうございます。
Illustrated by nagisa.
Masahiko Umeno
mumeno@redhat.com