Live from ITARC - An Introduction to Patterns

This introductory session covered patterns and was a useful recap. A pattern is a reusable solution to a recurring problem. Patterns can be at a high level (architectural pattern) or object oriented design level (design pattern) or indeed at any number of other levels or about other topics. Patterns have a number of elements:

• Name
• Synopsis
• Context/Problem Statement
  Some information about the drivers for this pattern
• Forces
  Why would you use the pattern
• Solution
  An explanation
• Consequences
  Pros and Cons
• Implementation
• Related Patterns
  Patterns combine into Pattern Languages of related patterns.

All of this got me thinking about EDM patterns - what are they? what can I say about them? This is my last post from the conference as I am off home tonight. If you live in the Washington DC or San Diego area, consider coming to the ITARC events there - more at www.iasahome.org.

Technorati Tags: architecture, pattern

Comments

[Roeland Loggen]

Decision patterns - interesting concepts!

A number of pattern-thoughts pop up:

1. Decision based on available (process instance) data
Example: if (insurance.amount > XXX) then

2. Decision based on automated complex data analysis, available in process (or outside - say a credit scoring engine).
Example: if (complex_calc(d1, d2, d3) then )

3. Decision based on human knowledge & experience - 1 person
Example: if (decision_by_role(xyz) == ... then ....)

4. Decision based on human knowledge - multiple persons, not at same time (e.g. sign off each), with various authority rules (if X out of Y then...)

5. Decisions based on human knowledge - multiple persons, same time (e.g. meeting)

regards,
Roeland