« Home

How Code Effects Fits Into Your Existing Applications

One of the most common questions we hear from executives and technical leaders is simple:

What exactly does integrating Code Effects involve?

The short answer is: much less than most people expect.

  • You don't replace your existing applications.
  • You don't migrate your data.
  • You don't deploy separate decision servers.
  • You don't redesign your architecture.

Code Effects becomes part of the software you already have. It's that simple.

Think of It as Another Library

From a technical perspective, integrating Code Effects is no different from adding any other third-party .NET component to your project.

Your developers reference the Code Effects assemblies, define the business data that rules should work with (we call these Source Objects), extend your existing data storage to save and retrieve rules in a manner consistent with the rest of the application, optionally implement authentication and authorization for rule access, optionally introduce rule versioning and testing workflows, and embed the Rule Editor wherever rules need to be created or maintained.

Everything else remains exactly where it already is:

  • Your databases stay the same
  • Your APIs stay the same
  • Your authentication systems stay the same
  • Your deployment processes stay the same

Your applications continue doing what they already do - except that business decisions become configurable.

Early versions of Code Effects included generic mechanisms for features such as rule access control and version management. However, feedback from our customers was overwhelmingly consistent: organizations already had established authentication systems, approval workflows, auditing requirements, and versioning practices in place, and they preferred to integrate rule management into those existing processes rather than adopt another vendor-specific implementation.

We listened.

Instead of introducing and continuing to develop and support features that could conflict with your architecture and operational standards, we chose to leave these concerns entirely in your hands. As a result, modern versions of Code Effects focus exclusively on what they do best - rule authoring and evaluation - while allowing you to leverage the authentication, authorization, versioning, testing, and governance mechanisms your organization already trusts and uses every day.

How Rules Are Created

Rules are authored through a web-based editor that can be embedded directly into your existing web applications.

Users interact with menus and business-friendly statements instead of programming languages. For example, a user might define a rule such as:

If the customer has been with us for more than three years
and annual spending exceeds $25,000,
apply the premium discount.

The resulting rule is stored as a simple XML document that can be saved wherever your organization normally stores application data. For most organizations, that means an existing SQL database. No specialized repositories are required.

How Rules Are Evaluated

When your application needs to make a decision, it simply retrieves the appropriate rule and evaluates it against the source object it already has. For example:

  • A loan application arrives
  • An insurance claim is submitted
  • A customer requests a discount
  • A workflow reaches an approval step

Instead of executing hard-coded conditions scattered throughout the codebase, the application asks Code Effects to evaluate the rule against a source object - the business object that represents the loan application, insurance claim, customer request, workflow instance, or any other entity involved in the decision.

The engine returns the result immediately. Your application then decides what happens next - either by continuing its normal execution flow or by allowing the same rule to invoke designated public methods, called Rule Actions, which can take over the subsequent execution of the business logic.

One Rule's Journey

A simple way to understand how Code Effects works is to follow the lifecycle of a single rule:

  1. A business user creates or updates a rule using the embedded Rule Editor.
  2. The rule is saved as XML in your existing database or storage system.
  3. Your application retrieves that rule whenever a decision is needed.
  4. The Code Effects engine evaluates the rule against the business object you provide.
  5. Your application acts on the result.

That's it.

No separate services. No synchronization processes. No proprietary infrastructure. Just rules moving through the same applications and systems you already own.

There Is No Separate Runtime

Many decision platforms require dedicated servers, cloud services, synchronization processes, or proprietary execution environments.

Code Effects does not.

The evaluation engine runs inside your application process. If your application runs successfully today, it already has everything needed to execute rules tomorrow. Scaling decisions is no different from scaling the application itself.

Existing Teams Usually Need Very Little Training

Developers typically become productive within hours because the integration model follows familiar .NET patterns.

Business users generally require only a brief introduction to the editor. Because rules are assembled from guided menus rather than written as code, business users focus on expressing policies instead of learning syntax.

Many organizations simply introduce the editor as another screen within their existing administrative portal.

You Decide Who Owns Decisions

Every organization is different. Some prefer that only developers create rules. Others allow analysts and operations teams to maintain them. Many use a review process where business users propose changes and technical teams approve them before deployment.

Code Effects supports all of these approaches because rules remain under your control. You decide who can create them, modify them, approve them, and publish them.

Typical Implementation Timeline

For most projects, the first working prototype takes days rather than months.

  1. Identify a business process with frequently changing logic.
  2. Define the data that decisions depend on.
  3. Embed the Rule Editor into an existing administration interface.
  4. Store rules in the application's existing database.
  5. Replace selected hard-coded conditions with rule evaluations.
  6. Expand usage gradually as confidence grows.

Organizations often start with a single use case and extend adoption naturally over time.

What Changes and What Doesn't

What changes:

  • Business logic becomes configurable.
  • Decision policies become easier to maintain.
  • Rules can evolve without modifying application code.
  • Non-developers can participate in policy definition.

What stays the same:

  • Your applications.
  • Your infrastructure.
  • Your databases.
  • Your security model.
  • Your deployment processes.
  • Your ownership of data and logic.

In other words, Code Effects does not ask you to rebuild what already works. It simply gives your software the ability to adapt when your business changes.

You don't adopt Code Effects by replacing your software. You adopt it by teaching the software you already have how to adapt to change.

l102

p101

×