I was reading some work by Randy Heffner and his colleagues at Forrester recently on Digital Business Architecture - here and here. He defines a Digital Business Architecture as:
An IT Architecture centered on business metadata on which IT solutions act in a unified and consistent way to deliver rapid business change
Wow - this sure sounds like something that would leverage EDM to the hilt. If I think about customers implementing an "enterprise policy hub" or "enterprise decisioning backbone" they are trying to get control of business metadata (rules) so they can build systems that use this in a unified and consistent way to deliver on agility.
Randy correctly identifies business rules as a form of business metadata for policy definition and goes on to give some great examples. Interestingly one of them strikes me as a perfect example of where rules could have played a role - the process for calculating and approving sales commission. If the rules for calculating this were managed in a business rules management system where the business owners (sales management) could maintain the rules themselves and where, perhaps, the rules could be combined with the pricing engine used by the sales folks, then the calculation could be automated and the whole process dramatically simplified. Indeed a couple of mobile telcos do exactly this with Blaze Advisor, using it to calculate the (notoriously complex) sales commissions on mobile phones and plans .
Later in the paper Randy is talking about how to get to the digital business architecture and he has a step called "how can we optimize each step in the process". This is where EDM comes into play. With its focus on operational business decisions, EDM is uniquely focused on how data, analytics, policy and regulations can be applied/enforced to make the most effective and most efficient decisions at each step - most precise, most consistent, most agile. For instance, instead of using the RFID data to alert someone to a shipment risk, why not take remedial action while that person is asleep? Randy is rightly dismissive of requirements definition and documentation as a vehicle for this kind of thing. Regular readers of my blog will know my position on this but there is a lot more on this here.
EDM is part of how any decision-rich business can deliver on the digital business architecture. If you have decisions, and you want this kind of technology/business integration, you need EDM.
BTW I also blogged about Randy's phrase "Concurrent Business Engineering" and how rules could deliver on this over on ebizQ.
