|
The intent of the Capstone Newsletter is to keep you informed of industry trends that can shape how you do business. You will also find information on upcoming technology events as well as interesting and timely technology articles.
We hope you find the information in this newsletter relevant. Your feedback on these or potential future topics is welcome at feedback@capstonec.com.
This Capstone newsletter continues to show a high-level summary
of using business rules with the Rational Unified Process (RUP).
The beginning part of the newsletter can be found at
Business Rules and the Rational Unified Process Working Together Part 1
As mentioned in the last newsletter, business rules and
the RUP do fit together from a phase perspective but what are some
impacts to the RUP disciplines? This newsletter attempts to summarize
some of those impacts.
The disciplines of the RUP encompass the different team aspects that
help ensure an successful delivery. For more information on the RUP
disciplines please review:
http://en.wikipedia.org/wiki/Rational_Unified_Process
Business Modeling
The business modelers are responsible for capture and
dissemination of business rules albeit it is not their major focus. As
the business process is documented the business rules can be drawn out
from the user and stored in the business rules repository (BRR). The
business rules document is used to capture the business rules populated
by IBM’s SoDA or another tool to give the business rules in a
document format. The business rules survey can be used as well to
capture and disseminate business rules.
Requirements
The business rules strategy is extremely important to
the requirements discipline. Decisions are needed upfront to ensure
successful capture and dissemination of business rules. Some key
questions need to be answered before the requirements can be properly
captured.Here is a list of such questions:
- Where will the business rules be stored?
- What idioms will be followed on business rules capture and storage?
- When does a business rule live in a use case, when outside?
- How will changes be disseminated to consumers of the artifacts?
- How will ownership be documented and controlled?
- How will business rules be approved? How are they changed?
- What are the standards for documenting business rules?
- How will ambiguity be resolved?
- What is a use case process step and what is a business rule?
- What is right level of detail?
- What key criteria impact the implementation of the
business rules? (On one project we decided upon volatility and number
of executions. This helps guide the analysis and design team.)
These questions do not have to be answered immediately
but there should be clear direction from the project management team.
If there isn’t clear direction there is a great possibility
of business rule failure. The business rules will have a great impact
on the use case model and specifications. The business rules may live
inside or outside the use case specifications. It is important to have
consistency in the approach across the team. The use case standards and
idioms should reflect how business rules should be documented. The BRR
will be used by both the requirements and business teams.
Analysis and Design
The business rules need clear analysis, design and
implementation patterns. It is important to establish these patterns
and distribute them among the team. Also important is that the team
understands how the implementation impacts of the business rules. The
architecture should clearly show (and demonstrate in the executable
architecture) how business rules effect the architecture. It should be
clear from the artifacts that business rules implementation and change
control is well documented and unambiguous. Each architect and designer
should have rudimentary business rules engine (BRE) implementation
skills. This helps ensure a successful design. The analysis and design
models show how business rules are handled. The design patterns show
how all designs should handle business rules. It is important that
these are not duty-free abstractions but real patterns that have
successful implementation examples. The method of business rule access
to persistency needs to be mapped out in the data model.
Implementation
The implementation of the business rules is greatly
impacted by the choice of the business rules architecture. If the
architecture uses a robust BRE, then the implementation needs to
correctly add business rules, access information and execute
individually. If the business rules’ implementation pattern
is Java properties files, then care is needed to ensure the design
patterns are implemented. The unit testing of business rules depends
much on the architecture as well. It is important that business rules
can be tested independently. As part of the implementation test, suite
automated business rules should be considered. The component (code,
configuration, database, etc.) artifacts are affected by business rules
implementation. The flow of the business rules whether an automated or
manual process should be well documented. The flow should be tested
during implementation. This may involve the business users modifying
rules and viewing the results directly.
Test
The test team must be able to validate the business
rules prior to implementation. The testing process of business rules
must be clearly understood. This testing process is continuum from
testing with test data inside the BRE - to allowing the business rules
to execute and test via only test cases. The pattern of testing needs
to be decided and followed. A key tenant of business rules is that it
will most likely change and there should be minimal impact to the
executing system. The business rules testing during transition needs to
be documented and understood. The test case, test strategy, test plan,
and test automation architecture are affected by business rules.
Deployment
Business rule deployment depends on the business rule
implementation strategy. The use of a BRE impacts the builds and
configuration of the system. For example if using iLog’s
JRules
(http://ilog.com/products/businessrules)
the pushing of the business rules from test server to a production
server must be aligned with Java deployment and other configurations.
Additionally clear direction is needed for how the business will change
rules in production. The business rules formal testing and deployment
needs to be documented. The main deployment artifacts that are affected
by business rules are deployment unit and end-user support material.
Configuration and Change Management
Business rules configuration and change management is
essential for successful business rule implementation. The business
rules provide the business users easier access to change the
functionality of the system. The control of the business rules is
paramount to successful transition. Most likely there will be different
procedures and processes for different types of business rules. For
example, if the business rule is “IF customer state of
residency is WY|CO then state tax rate is 5%” could be a rule
that the business can change the state of residency or the rate, but
not where the data is evaluated from. The owner of the rule might be
able to change parts of the rule but it will still require regression
testing. The main deployment artifacts affected by business rules are
the configuration plan and workspace.
Project Management
Business rules will effect the project management by
impacting the risk of the project. Depending on maturity of the
business rules process and environment, the risk of the business rule
may be high. If the risk is high, then project management needs to
track and mitigate appropriately. The business user participation and buy-in
is critical to project success. At a minimum the iteration plan should
include business rules implementation during elaboration and most
likely during early elaboration. The software development plan and
iteration plan are affected by business rules.
Environment
The business rules will effect the environment based on
the business rules architecture. The environment discipline has to
include key business users and their access to the business rules
engine, development, test and production. This is unique with business
rules because the business users effect change in the running
system. The tools, development infrastructure and development case will
be impacted by the use of business rules in the project.
Conclusion
Business rules evolvement has gained momentum in the
information technology industry. The RUP provides a malleable process
that can be modified to handle business rules. Key decisions and
milestones early on in the business rules/RUP process assist with
implementation of business rules. With proper attention and direction
the business rules and RUP leads to the business user getting what they
desire: a robust system that can be modified by the business.
|
