In an earlier post on Agile Enterprises, I covered this briefly.This post intends to fully take up the subject .

Here are some of the major engineering issues that arise parallel/outsourced development scenario.

Concurrent Engineering

We want to be able to develop solution parts, capabilities in parallel. In case of a distributed development environment, this becomes rather difficult.

1. Sharing object models that are changing often will mean constant changes in the offshore team leading to constant code changes and hence bugs.
2. Using Business Rules Management Systems, you can develop you the rules that drive decisions independent of the object model that is used by the rest of the application.
3. The rules can be developed on business terms or on XSD’s that can me mapped separately to the application models.
4. The (rule) developers (in the off shore team) do not have to worry about development changes in the on site teams.
5. If you think about this, the policy automation and the rest of the system development can proceed in parallel and still mesh together just fine at the end.

Well Defined Integration & Clear Separation

1. The on site developers have a clear interface with the rule engine and need not worry about the internals of the rules as long as their inputs and output interfaces are well defined
2. This is especially useful when an SOA architecture is envisioned.
3. It will be possible to build a truly independent & reusable Enterprise Rules Service Layer with this model
4. Because the rules and hence the business logic is so clearly separated, development & integration responsibilities are very clearly defined leading to ease of management.

Ease of Testing

1. The test cases typically come from the business.
2. The business logic can be tested independently of the application rigorously using testcases captured in Excel sheets (1 row, 1 testcase)
3. Regression testing for changes also follows the same pattern.
4. Your rules can be tested independently of your application. This eliminates the need to go through the whole Application testing cycle for business policy/rule changes (For example Rate Sheets in Mortgage can be fed into the BRMS directly and tested for correctness)
5. The test cases for the rules can be created and captured independently by your business teams.

Reuse & Maintainability of Core Assets

As I have been always saying, business rules are core organizational assets? You need to know how you take decisions. If you do not, you cannot control, and therefore cannot improve.

1. Business Rules represent critical organization knowledge
2. They are the digital executable, visible representations of how the organization takes it’s decisions.
3. When captured using Business Rules Management Systems, you gain visibility, auditability and most of all control over your operational decisions
4. You are now truly enabled towards standardized policy deployment across the enterprise.

Maintenance & Configuration Management

1. I have spoken about Rule Repositories and business user rule maintenance earlier and governance issues earlier.
2. Because rules can be captured, implemented and tested independently of the application, the lifecycle of business rules can follow a different path from the rest of the application.
3. Business Rules changes are business driven and not IT driven. Rule Repositories allow for the regular versioning and also enable specialized usecases like Historical Rule Invocation
4. Once the major rules are set up by the offshore teams, regular changes to the rules (daily ratesheets) can be uploaded by the business. IT can handle the other more complex If Then rules that might be difficult for the business teams to follow.

Conclusion

I believe that Business Rules technology and methodologies offer organizations a very effective way to outsource their business system development, and truly achieve the benefits of effective outsourcing while managing to retain and improve alignment towards business goals.