Bruce Silver had an interesting article recently on The Next Innovation in BPMS in which he discusses the need for repository capabilities in BPM. Bruce makes the point that “next generation” repositories for process management must not only support process models, they must also support “decision models”, business object definitions, performance measurement information and service metadata for deployed services.
Today most of these things are in separate repositories and, frankly, I am not sure this is going to change. For one thing the challenge of a single repository handling everything is great and past experience with “the big repository in the sky” is that it cannot be made to work. Specialization is just too valuable for some of the pieces/people involved. As such one ends up with a federated repository with multiple specific repositories each able to query and link to others.
For this to work I think there are a couple of key features:
- Strong query APIs for all so that one repository can use dynamic queries to access others
- Pre-defined impact analysis so that changes can be analyzed for their impact across all the repositories
- Extensibility so that a repository can be extended to have hooks to another for explicitly linking objects in one to objects in another
- Standards support
- User interface elements suitable for mashup/portal use so that a user can build the view they need
