Introducing the concept of Change Oriented Architecture.

1. Daniel Selman, Product Architect – IBM WebSphere ILOG BRMS
Paris Java User Group, November 2010
Enabling Agile Business
and IT Collaboration
© 2009 IBM Corporation

2. Things change.
© 2010 IBM Corporation

3. Expect it. Design for it.
© 2010 IBM Corporation

4. Change Oriented Architecture.
© 2010 IBM Corporation

5. Externalize your data from your code.
© 2010 IBM Corporation

6. Create reusable services.
(if you can afford to)
© 2010 IBM Corporation

7. Externalize your volatile business policy from your code.
© 2010 IBM Corporation

8. How many change processes do you need?
1. Code
2. Configuration
3. GUI
4. Rules
5. Processes
6. Data
7. Models
8. Transformations
9. Topology
10.Etc.
© 2010 IBM Corporation

9. What metadata do you need to govern your changes?
© 2010 IBM Corporation

10. Who initiates a change?
– How do they know that change is required?
Performs the change?
Validates the change?
© 2010 IBM Corporation

11. Do you need side-by-side execution of configurations?
(Can you afford it?)
© 2010 IBM Corporation

12. How will you audit what changes were made?
(for how long?)
© 2010 IBM Corporation

13. How do you ensure that the pre-conditions for a change are in-
place or planned?
© 2010 IBM Corporation

14. Is the change comprehensible to a human being?
© 2010 IBM Corporation

15. Your job as an architect/developer:
Build a “container for change”
© 2010 IBM Corporation

16. Cross-disciplinary work, requiring:
 A solid knowledge of the business
 An appreciation of human behavior
 Deep (and broad) technical skills to choose the right
technologies
 An understanding of governance concerns
 Top-down management support for funding
 Abhorrence of over-engineering…
– Design for expected changes
© 2010 IBM Corporation

17. BRMS cannot solve all these problems
(but it can help with many)
© 2010 IBM Corporation

18. Short demo of a change cycle with ILOG BRMS
© 2010 IBM Corporation