Role of Rule architect

Document options Print this page Original ENGLISH Level: elementary Arun chhatpar, Software architect, omniviz July 31, 2008 Business Rule architects play an important role in designing well-organized and intuitive business rule models to help technical and business participants understand business rule models. This article discusses the importance of this role and uses the business rule development lifecycle to describe the role of the Rule architect in creating reliable and scalable business rules. What are the responsibilities of business rule architects? As in the previous article "business rules getting started" (seeReferencesAs described in. The Business Rule Management (BRM) System Automates and manages decisions based on business rules. With the increasing popularity of BRM systems, more enterprises begin to implement these systems on a large scale, making them more and more complex. Therefore, preliminary design is very important. The Business Rule architect is responsible for correctly designing these BRM systems. The Business Rule architect cooperates with the business owner and IT personnel to build an overall view of the business rule policies of the Organization. The rule architect is responsible for converting the business needs of the Organization into a reliable and stable software system. The rule architect undertakes the task of reducing the overall cost of creating and maintaining business rules by designing and constructing simple and reusable components. Back to Top Quality of efficient rule architects As a rule architect, you not only need technical skills, but also effective communication skills. Let's take a look at some of the most important qualities that rule architects need: Expertise in business rules-Rule architects must have experience in designing and developing business rules and systems, as well as experience in using various BRM tools and systems. Understanding Business capabilities-understanding the driving force behind business rules is important for designing robust systems. Beyond the vision of an existing system-just like an enterprise architect, a rule architect not only needs to consider the system being designed, but also needs to understand how it adapts to the enterprise's vision and the overall architecture of the Organization. Strong communication skills-the ability to communicate effectively with business and IT personnel is crucial to the success of business architects. Proficient in technology-Rule architects must have hands-on software development experience to meet the challenges of building an excellent system design. Ideally, rule architects will have different key positions in the IT organization, which helps them understand system bottlenecks and limitations and help them design and plan the right solutions. Now that we have learned the qualities required by excellent rule architects, let's take a look at the responsibilities of Rule architects in each step of the Business Rule development lifecycle. Back to Top Business Rule development lifecycle The purpose of the Business Rule System Architect is to separate business considerations from the logic code and then combine them into a system that is easy to manage, to allow business users to create and update rules using a syntax similar to English. Like any software system development, the business rule system has a defined lifecycle. The three main steps in Rule development are design, development, and maintenance. Let's take a look at each step and the role of the Rule architect in each step. Rule Design The first step for rule architects in the lifecycle of Business Rule development is design. The sub-tasks involved in the design steps include: Determine business rules-Rule architects need to understand which rules must be added to the BRM system. This is a long iteration and involves a large number of interviews, meetings, and discussions with business users. Rule Classification-Rule architects need to classify rules that have been divided into corresponding categories. Some examples include front-end verification rules, backend workflow rules, elimination rules, and hierarchical placement rules. Define template-Rule architects use BRM tools to define components and templates. In this step, define the overall structure of the business logic as a template and make some specific parts of the specified template editable. Then the business user uses RMA (see the following description) and edits these values according to their business needs. You can use any controls and labels suitable for the business environment to display editable values on the webpage. After templates are defined, these templates serve as the guiding principles and starting points for business users to write rules in BRM systems in a language similar to English. The most common components provided by almost all industry-leading BRM tools are rule and rule set templates, decision tables, and decision trees. In a decision table, rows and columns represent different conditions, and result operations are defined by their intersections. The decision TREE Graphically describes the related condition chains of an operation. Create a user interface and put business rules into the BRM system-the rule architect must provide the business users with an interface for creating rules, called rule maintenance application (RMA), as shown in 1. Create rules-the rule architect must then use RMA to create rules. Figure 1 shows the rule design process. Figure 1. Highlight the complete BRM system architecture of the Business Rule Design Process 1. IT staff use the BRM integrated development environment (IDE) tool to create templates. business users use these templates to write rules from RMA. The rule architect plays an important role in this process. At the beginning of the design process, the rule architect helps determine the rules correctly. Correctly determining rules helps keep unnecessary rules away from the rule repository. Rule architects must ensure that all rules are captured by conducting a large number of interviews with business users and using techniques such as requirement collection. Architects can also use tools such as IBM Rational requisitepro to simplify the process (see the "rational requisitepro lets you survive" column ). Rational requisitepro allows you to survive The IBM Rational Software portfolio includes an integrated tool named rational requisitepro for managing requirements. One of the main functions of the software is to manage project-related documents. You can manage documents created by different business users and combine them to create a large rule stack. You can download the trial version and use IBM developerworks (seeReferences) Learn more about rational requisitepro. Once confirmed, the rule architect must ensure that the rules are categorized into appropriate categories. It is important to classify rules correctly, because classification affects all three steps (design, deployment, and maintenance) of the rule lifecycle ). The rule architect must then use the correct component to define the template. What are the components in the BRM system? They are prototype or build blocks, and rule designers can create rule sets in logical form. Examples of components in the BRM tool include rule set, decision table, decision tree, and scorecard. Should you use a rule set or decision tree to define a group of rules? The rule architect must decide which rules to use to define a group of rules and ensure that the correct components are used to define them. The rule architect must also consider code reusability during design. This shows the importance of the technical knowledge mastered by the architect. The rule set you designed must be both scalable and reusable. After a business user has created a rule in RMA, the next step is to deploy the rule with your existing application. Rule deployment As mentioned above, the rule architect's vision must be beyond the current system. This is not only related to which rules enter the system. The rule architect must also consider how the system being developed establishes connections with existing applications. Most business rules implement or replace existing legacy applications, or serve as sub-components of a large system architecture. The complexity introduced by such hybrid systems makes integration of business rule systems more difficult. The complete integration process between the legacy system and the new application is not covered in this article, but let's take a closer look at the steps involved in the deployment process. The rule architect must select the target implementation type. Using the current BRM tool, you can use different deployment options for the rule engine. Some of the options include: Inline Java application-runs the rule engine as an inline Java application. Web service deployment-you can deploy the rule engine as a web service and access other applications through the standard Simple Object Access Protocol (SOAP) interface. Enterprise ans (EJB) in the application server -- integrates the rule engine into the application server and runs as EJB. The rule architect must define interfaces to interact with existing external and legacy applications. This step includes integrating the new business rule application with other applications that have been running for a period of time and the enterprise information system (usually known as the "Legacy" system of the enterprise. Enterprises cannot afford any interruptions to these legacy systems. Therefore, the rule architect must ensure seamless collaboration between the new system and existing applications. This may involve making your new system public to other applications or implementing other system interfaces to interact with them. The rule engine must be deployed by the rule architect. Figure 2 illustrates the rule deployment process of the BRM system. Figure 2. Highlight the complete BRM system architecture for business rule deployment and integration with external and legacy applications Figure 2 shows that the system is quite simple, so it cannot be a real case. In fact, the rule architect should be very careful in creating interfaces between the rule engine and external and legacy applications. The rule architect must consider the performance of the rule engine rather than making it a limiting factor for the overall performance of your system. This is different from the performance of the system where the rule engine is deployed. On the contrary, this refers to the performance of the rules engine, and depends on the amount of time it takes to execute the rules and return the results to the called application. There are several factors that will have a negative impact on performance, such as incorrect data model design (for example, your data model has a need for multi-dimensional arrays ). It is always better to keep simple design and use of one-dimensional arrays. Poor interface design, hardware restrictions, and cross-system integration can also reduce overall system performance. From the perspective of the infrastructure, the rule architect must facilitate the correct management of the rule repository. You can centrally organize business rules and model business processes and components based on tasks to achieve correct management. Rule architects must encourage shared infrastructure and applications to reduce costs and improve information flows. Correctly managing the rule repository also allows architects to reuse business rules and components in new business domains, quickly enter new markets, and cover specific components as needed to address new requirements. Rule deployment should be counted as it tasks, and business users are not involved. Rule deployment is involved again in the final process of rule maintenance. Rule Maintenance The final process in the lifecycle of Rule development is rule maintenance. Business users work with rule architects to maintain rules in a continuous process. This process allows business users to modify rules without asking it staff for help. The idea of the BRM System is to provide business users with full control over business logic changes without having to work with IT personnel. The key here is to have a public rule repository. Understanding the rule repository is very important to understand the necessity of Rule maintenance. The repository must be accessible to various applications. Figure 3 helps illustrate this sharing. Figure 3. Architecture view of BRM System As you can see, all three components (IDE, RMA, and rule engine) use the same public rule repository. The idea here is to provide a public foundation and still allow all components to access business rules independently. Therefore, even if the rule engine points to the same repository at runtime, business users can still make changes to the rule, and these changes are immediately picked up by the rule engine without the intervention of IT personnel. Of course, the Rule architect must still manage such operations as release management and version control. However, this is the ideal way to work. The rule architect must provide a rule change interface for business users. This interface is the same as the RMA created during Rule Design for business users to manage and update rules. The created template is packaged and usually deployed on the application server to provide a simple Web interface for business users to manage rules. Rule architects must create version control policies. Version Control provides records of all changes. It is equally important to combine the changes made by the business users so that you can roll back the changes in case of problems. The rule architect must also create a code release policy. Although business users may not be accustomed to publishing management, they are not allowed to make changes at any time. The rule architect must execute a feasible release policy and notify business users to follow the policy. When the policy is ready, business users can update the rules as needed according to the release plan. Figure 4 shows the rule maintenance process for business users. Figure 4. Highlight the complete BRM system architecture for maintaining business rules using RMA As with the design and deployment steps, the rule architect also assumes specific responsibilities in the maintenance steps. However, at this stage of the process, the architect does not have much to deal with except to ensure that the new rule system is correctly deployed and RMA is always available for business users to change rules. Another role of the Rule architect is to create a simple and user-friendly interface. Rule developers usually create RMA pages, but architects can and should implement a simple way to design the appearance of the user interface (UI. This cannot be emphasized. In one of my work, a leading BRM tool was almost totally discarded because its ready-made UI was very difficult to use. Therefore, we strive to keep the interface simple. The work of the rule architect may sound simple and intuitive, but it may be one of the most challenging tasks for today's it. Back to Top Summary A good rule architect must fully understand the business rule field. This includes not only business rules and legacy application interfaces, but also the actual meaning of the system. In the face of specific systems to be implemented, they will propose a large number of different solutions and be able to choose the right solutions. I hope this article will help you better understand this challenging role. Back to Top Thank you I would like to thank my mentor and business rule system expert Deven Samant for providing guidance and expert advice for the text. References Learning You can refer toOriginal ENGLISH. The previous article:Introduction to business rules(Developerworks, February 2008) demonstrates the importance of a business rule management (BRM) system in bridging the gap between business and IT. Business Rule communityHaving a large number of articles and tutorials is a good place to learn more about business rules. Written by Mukundan agaram"The phased approach to mining business rules" (Business Rules Journal, vol. 8th, Chapter 5th, April May 2007)Provides an excellent example of how to mine business rules in the system. Written by Ronald g RossKnowledgeable articlesA good case about whether all rules are business rules is proposed. Create and deploy Business Rules(By Neil kolban, developerworks, October 2006) is an excellent tutorial on how to use IBM WebSphere integration developer to create and deploy solutions that use business rules, then test the solution in IBM WebSphere process server. WebSphere process server: the new foundation IBM provides for SOA(Author: Wolfgang kulhanek and Carol Serna, developerworks, February September 2005) is an introductory article about WebSphere process server and its service rule service components. Read articlesBusiness Rule Management SystemTo understand what the business rule management system is and what to pay attention to before choosing a business rule Management System for the enterprise. Business Rules for everyone blogIt provides enhanced knowledge and interesting discussions about business rules, design and architecture. Enterprise demo-management (EDM) blogIt is a good source of EDM articles and discussions. ArticleIBM WebSphere developer technical journal: Introduction to WebSphere integration reference architecture(Developerworks websphere, August 2005) provides an overview of the WebSphere information integration architecture. Obtain the latest versionBusiness Process Execution Language for Web Services version 1.1 Specification. AccessWebsphere Business Integration Server product siteTo learn more about IBM Websphere Business Integration Server. You will find technical documents, Getting Started articles, education, downloads, product information, and so on. InWebsphere Business integration zone: overviewFind references for IBM Websphere Business integration developers. ExploitationIBM WebSphere Training and Certification Resources. SeeRational EGL resource pageTo learn about the Enterprise generation language (EGL). EGL is the latest version of 4gl used to define the business rule logic. Rational Unified Process includes business modeling procedures, which focus on how to effectively understand business domains-including business rules.Learn more about Rational Unified Process (RUP). Obtain products and technologies IBM WebSphere process serverUse business rules as one of the server components of its Business Process Management Suite. TrialRational uniied process for Websphere Business Modeler plug-inTo understand how easy it is to visually define mission-critical business processes. UseIBM Rational requisiteproTo manage the documents created by different business users and combine them to create a large rule stack. Fair Isaac's blaze AdvisorIs one of several BRM tools. Jrules launched by ilogIs another BRM tool. Discussion ParticipateDeveloperworks blogTo join the developerworks community. About the author Arun chhatpar is an author who often contributes to IBM developerworks and has more than 10 years of software design and development experience, the fields involved include decision analysis, business rule management system, core Java, UI framework, and workflow orchestration. He is also a Sun Certified Enterprise architect and is currently in farmers Inc. engage in consulting and modernize the company's legacy systems by using enterprise decision management technologies such as blze advisor and PEGA rules.