JT on EDM

One of my regular readers had a question today about Enterprise Decision Management and the Software Development Lifecycle – the EDMSDLC if you like. Here’s what he asked:

We do Business Rules in our approach… I guess one question would be, where does EDM fit in a typical SDLC? [company] does Requirements, we have a method that takes us from Scope and Objectives, through business process definition, to deliver the list of statements that are “The system must…”.
This also makes me think again about the discussion “are business rules really requirements? because business rules exist whether you have a system or not”.

In the book we say “When you’re adapting an SDLC to include EDM, you need to consider four areas: identifying and managing decision services, managing business rules separately from requirements and as a model, integrating analytic models, and recognizing the impact of adaptive control.” Taking these one at a time we can consider the impact they have on the SDLC:

1. Identifying and managing decision services
   Identifying and managing the decision points for which decision services will be required and scoping out those decision services is part of business process definition in most modern software development processes. When working through the definition of a business process it will be natural to identify some of the business decisions that are required even if EDM is not your focus. Identifying hidden and micro decisions is often a new tasks but it fits well into this process. So much so that we have a standard consulting offering called the “Decision Discovery Process” for this work.
2. Managing business rules separate from requirements
   I won’t repeat myself here as I have an entry in the wiki on business rules and requirements as well as a couple of posts on   Use Cases, Business Rules and Decisions and Requirements, Dr Strangelove and loving change.
3. Integrating analytic models
   This can be a real challenge for IT organizations as the groups that usually work on analytics are quite separate. Two main issues need to be addressed. First it is essential to bring analytic modelers into the loop when doing data and object modeling. IT professionals need to see data, especially data for which significant historical data is available, as something that can be mined for new insight, new data items. Data can be available to a system even if it was never captured – a customer’s retention risk, for instance, might be entirely derived from other historical data. The second issue is one of model deployment – analysts and developers must work together to understand how the results of data mining and predictive analytics will be put into production. This requires collaboration around data cleansing, data integration and data manipulation as all of these are typically needed when building models. If no thought is given to deployment, you may end up with models you can’t deploy without writing a bunch of code.
4. Recognizing the impact of adaptive control
   I have yet to come across an SDLC that considers adaptive control and the development and testing of challenger approaches to decision making. Using adaptive control means never stabilizing the core logic of a decision, always testing and challenging it and always deploying and re-deploying new logic. Typically this means building in user-driven iteration into the maintenance plan so that this can be kept separate from more technical maintenance.

In general, many aspects of a traditional SDLC do apply when using EDM. There is “infrastructure” required that must be developed by IT such as glue code and definition of complex rules or rule templates. Once IT has completed this development, users have a way to make changes to the system without going through the usual SDLC, but building the environment to do this requires a proper software process. You do need this second, shorter and simpler process that goes from business requirement to the business user making and testing the change Users can also be allowed to push these into production but most IT departments still want at least a partial release cycle.This is a little like using a database in the sense that designing the schema is a fairly complex IT process while using a UI to add rows within the constraints of the schema is a user-centric task. Adding a rule is somewhat like adding a row to a table or modifying a particular column of a particular row.