I recently road-tested a presentation on "Change Oriented Architecture". This is something that I have been mulling over for a while, and something that I don't believe gets enough attention from CIOs and Architects. Yes, we need "agility", but actually the requirements go far beyond traditional SOA, BPM or even BRMS type approaches. Just as Decision Management considers Decisions to be enterprise assets, managing change also needs some overarching methodologies -- the practice of designing a software system for change is what I call Change Oriented Architecture (COA). SOA, BPM and BRMS are useful tools in our toolbox, but let's not forget the ultimate goal; building a software system that can respond rapidly to changes in the market to drive competitive advantage.
I am going to post the skeletal presentation here, in the hope that it will provoke some interesting discussion.
Expect it. Design for it.
Change Oriented Architecture
Eternalize your data from your code.
Create reusable services (if you can afford to).
Externalize your volatile business policy from your code.
How many change processes do you need?
What metadata do you need to govern your changes?
- Who initiates a change?
- How do they know that change is required?
- Performs the change?
- Validates the change?
Do you need side-by-side execution of configurations?
(Can you afford it?)
How will you audit what changes were made?
(for how long?)
How do you ensure that the pre-conditions for a change are in-place or planned?
Is the change comprehensible to a human being?
Your job: build a “container for change”
- 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
BRMS cannot solve all these problems
(but it can help with many)