Well I am at the Brainstorm BPM/SOA/EA/BRM/OPM conference in Chicago today and tomorrow and just attended the opening panel discussion where the various track chairs discussed how all these pieces fit together. There was a fairly nice picture of the overlap between the various elements, although I will have to work on a better one:
Each speaker made some good points:
- Brett Champlin made the point that Business Process Management as a discipline- looking at processes explicitly and trying to manage them - should be differentiated from a software stack. In the context of a discipline the management of business rules (also both a discipline and a software stack) was assumed to be part of business process management. While this does not imply that business rules technology is a subset of business process technology, nevertheless I have to take issue with it. It seems to me that decisions can be managed and improved without necessarily having to consider how the processes that use them might be better managed. Some companies only make decisions and some decisions are useful in their own right (e.g. in a self-service inquiry situation). I do agree that most decisions come up in the context of a process, but not all.
- Bill Ulrich talked a little about Enterprise Architecture and drew some nice distinctions between merely using web services wrappers and actually developing an SOA.
- Tom Dwyer of Yankee Group, who wrote a nice report on this "Adoption of SOA Should Stimulate Strategic Demand for BPM, BAM and BRM", showed a fairly standard SOA chart with a clearly defined business logic layer. It seems to me that business logic is almost a synonym for decision logic in this context and so it would make sense to always build the services in this layer using a decision-centric technology like a business rules management system.
- Barb von Halle of KPI spoke about business rules and presented KPI's Rule Maturity Model. Interestingly no-one in the audience would put their hand up and say that their rules were implemented consistently across processes and systems. No-one! Barb herself said that no-one is at the top level of the model and that they are only aware of 1 company at level 4 even.
Interestingly a book I reviewed recently -Use Cases - Requirements in Context - would be a great tool for someone trying to move from level 0 (no management) to level 1 (awareness). Moving on to level 2 is where a business rules management system comes in and, frankly, where much of the payoff comes.
- Alan Ramias talked about Performance Management and made a great point that you want performance (that is business performance) not technology or training (or methodology or...). The point of EDM, like any approach, is to improve business performance. If it is not doing so then don't do it.
Lastly there was a spirited discussion of how to get started with many different opinions - almost as many as panelists - but the best comment was one that you must start with the business objectives at hand as this is what drives budgets and energy. If the business objective is about improving a process, then focus on that. If the objective is to improve self-service for customers, then think about how to do that. Make sure the business objectives drive the technologies and approaches prioritized and not the other way around. Great advice for anyone adopting EDM or anything else for that matter.