¿Cuáles son los cinco desafíos principales al implementar un motor de reglas de nivel empresarial? [cerrado

Question

He compilado la lista según mi conocimiento, pero me gustaría enriquecerla y priorizarla utilizando las entradas de esta comunidad. Entiendo que tener un repositorio de reglas centralizado en sí mismo es discutible, pero podemos tener una pregunta separada para ello.

1. Adaptabilidad de los usuarios comerciales Para usar la plataforma para escribir reglas [definición, clasificación, decidir sobre reglas que podrían ir en un repositorio de reglas
2. Facilidad de invocación y consumo de reglas de una aplicación diferente
3. Portabilidad de reglas - [RIF (formato de intercambio de reglas) importancia?
4. Mantenimiento de reglas - BRMS [Sistema de gestión de reglas comerciales
5. Rendimiento del motor de reglas - [Cuánto, qué tan rápido y de confianza

Answer 1

Aquí está mi toma basada en la experiencia de 12 años con 3 motores de reglas (ordenados por importancia):

1. Capacidad para crear, editar e implementar reglas sin ninguna participación de TI después de que se instaló y probara el sistema. La capacidad de versión, aprobación, prueba y depuración de mis reglas es bueno tener, pero no crítica, siempre y cuando el motor venga con API normal, por lo que puedo construir esa funcionalidad yo mismo, como lo necesito. No estoy seguro de "la plataforma", solo dame una interfaz de usuario decente para la autorización y edición de reglas, preferiblemente la interfaz de usuario basada en la web.
2. El rendimiento de la ejecución de reglas debería ser excelente. No se puede enfatizar lo suficiente: los motores lentos casi siempre conducen a ganancias perdidas. En mi vida, el motor debe ser capaz de evaluar un conjunto de reglas de 50-80 condiciones (sin llamadas externas) menos de 2 milisegundos cada uno (aproximadamente 1.5 milisegundos en promedio es bueno, 0.5 milisegundos es excelente). Debe ser seguro de hilo, todas las evaluaciones de reglas deben ser completamente independientes entre sí y del motor en sí (que no sea el almacenamiento en caché de reglas).
3. Las reglas deben presentarse en formato XML para que se puedan guardar en cualquier lugar. No me importa qué tipo de formato sea mientras funcione y permanezca consistente entre las versiones del motor. Dudo que haya una gran necesidad para "compartir" reglas entre diferentes organizaciones. Definitivamente no espero compartir mis reglas con nadie :) Los repositorios de reglas pueden ser totalmente malvados simplemente porque es posible que necesite trasladar mis reglas de un almacenamiento a otro (por ejemplo, en caso de fusión o asquisición de todo el sistema por parte de otros. con otros tipos de almacenes). Debe estar bien siempre que la marca de motor permanezca igual. Las reglas son solo conjuntos lógicos. Debe ser completamente irrelevante donde se almacenan en este momento. Si el motor no puede solo cargar una regla en un formato esperado desde cualquier lugar, no necesito ese motor.
4. La capacidad de crear, nombrar y guardar pequeñas reglas y luego combinarlas en conjuntos de reglas por sus nombres sería una gran ventaja.

Todas las demás características de los motores de reglas que se me ocurren en este momento son irrelevantes para mí y para lo que hago. Espero que esto ayude.