What is a business rules analyst? Is it really a new role?

The term business analyst is not new. How is this new role of the business rules analyst different from the role of a business analyst? A business analyst is responsible for analyzing the business needs of their clients to help identify business problems and propose solutions. A business rules analyst, however, can be thought of as a business analyst with a focus on business rules. The role's primary objective is to focus on separating rules from code.

You do not need a special degree or qualification to become a business rules analyst, but you should have experience as a business analyst. Analytical skills are important for a business rules analyst to discover, capture, and express business rules in simple English that is easily understandable by business peers as well as the IT people who are going to design the business application. It is also useful for a business rules analyst to have an understanding of object-oriented programming concepts. A business rules analyst doesn't necessarily need to have working experience as a software developer, but that experience certainly helps them appreciate and implement the reusability aspect of software development.

The skills needed for this new role are very similar to that of a general business analyst, but the focus and day-to-day responsibilities are quite different. For example, it would be the business analyst who facilitates sessions to capture business rules for a new business application, whereas the business rules analyst
would ensure that the extracted rules reflect the business intent and will result in the desired business behavior. The business rules analyst also uses these sessions to understand how rules are enforced, how they are going to change, and how rule-related issues such as conflicting rules would be resolved.

The previous figure shows the role each expert plays in the rules application development cycle. There are four steps involved, as explained next.

1. Define the business application Based on real market need, business owners decide to introduce a new product. The key players in this step are business owners and business analysts. After an in-depth feasibility study and quantitative analysis, they define the requirements for the new application. The majority of work at this step is done by the business analysts.

2. Discover rules The requirements then come to the business rules analyst, who goes through the documents and extracts business rules from these requirements. The business rules analyst comes up with a list of rules in the form of structured natural-language statements that clearly, completely, and concisely express the rules to be implemented in the application. The business rules analyst must use his or her knowledge of process modeling and fact modeling to discover these rules. This step also involves validating the rules and developing scenarios for testing.

3. Create a framework for writing rules In this application design and development step, the business rules analyst works very closely with rules architects and rules developers to help them design the application in a way that ensures that the rules reflect the business intent and that the application will result in the desired business behavior. The key players here are business rules analysts, rules architects, and rules developers. The architects design the framework for business rules analysts to write the rules in a simple, English-like language. This is the most important step, because the business rules analyst has to make sure there is no redundancy in the rules while also helping the rules architects make components that will be reusable in other similar applications. The business rules analyst also structures the rules properly based on a logical model and works with the rules architect to help design the application in the BRM system. The rules architect along with expert developers then create a rules application, known at this stage as rules templates. Rules templates are guiding models that business rules analysts use to create the actual rules.

4. Create and manage rules The final step is to create or add the rules to the application. The business rules analyst uses a simple Web-based user interface to create rules for the first time. The business rules analyst uses the same interface to manage rules in the future. You might have noticed that the business analysts primarily interact with the management and business owners, whereas the business rules analysts must talk to all levels involved in developing the actual solution that the business rules are part of.

After the rules are created and tested, they are deployed and interfaced with other logical components of a system. A good business rules analyst elicits the invaluable knowledge from the business experts, digitizes it, and helps manage it in the most efficient manner possible.

Why Agile BI Needs an Agile Architecture

Agile development has been sweeping through application development teams (and more recently BI teams) across the public and private sectors alike. We’ve seen development methodologies come and go over the decades; today we’re embracing terms such as “scrum,” “sprints,” and “refactoring” into our everyday vocabulary. With each one of these methodologies, the driving force has always been to improve aspects of our value delivery. Information consumers are interested in quicker delivery of information, and government agencies need to act quickly to meet regulatory requirements.


Organizations of all types and sizes want lower the risk of projects not meeting intended business needs. Projects delivered in smaller increments will reduce risk, deliver valuable increments faster and effectively manage ever-changing project requirements in a fast-paced world.

Such needs drive development methodologies to incorporate short delivery cycles, partnerships, and fast failures (to reduce losses) while not worrying about formal requirements processes that can be rigid. However, when the organization wants the benefits of being agile, the whole system of information delivery -- not just the developers’ methodology -- has to be agile.

Agile architecture doesn’t immediately come to mind when we think about agile BI. Some might even jokingly say that it’s an oxymoron. However, information delivery does create and run on an information platform and architecture. Architectures represent solid foundations and standards that emphasize consistency that will stand the test of time. This may sound as though it’s the opposite of being agile and tactical -- or of delivering quickly. We need to understand that being agile is a philosophy and the same benefits enjoyed by agile developers are gained in building information architecture.

Here are some of the principles that I have found successful in bringing architecture and platform evolution into the agile model.



Refactoring Architectures


The data warehouse architect needs to recognize that just as information delivery projects add value to customers, their DW architectures make it possible to deliver those projects efficiently and reliably. Similarly, customer demands change rapidly, as much the underlying architecture. It must continually change and evolve.

We grow into our vision of data warehouse architecture with each project delivered and by mercilessly refactoring and revising the architecture. Classic architectures and principles should be the guidelines along the way, of course. TDWI’s BI Maturity Survey reinforces that data warehouses naturally evolve over time -- from infant stages to being a sage. Conforming dimensions, populating an EDW subject area, and consolidating staging areas are examples of refactoring, and having a mindset open to such changes allows agile BI projects to be completed quickly without concern that developers will ignore architectures, create information stovepipes, or run into dead ends.

A physical data warehouse architecture typically starts with a single server and a few hundred gigabytes of data. By the time it’s a teenager, your warehouse architecture must have matured to handle dozens of special-purposed server and hundreds of terabytes that serve an ever-growing variety of enterprise users tackling an ever-growing variety of BI tasks.


Specific architecture-based projects need to be treated the same as agile BI projects but use separate sprints and defined as distinct projects following BI project implementations. Typically refactoring happens about every six months for younger data warehouse architectures that are focused on initial deliveries and 12 to 18 months for more mature data warehouses focused on efficiency and consistency. Always look for opportunities that simplify the architecture, maintain or improve consistency and consolidate patterns in the architecture while not removing any functionality. Keep in mind that refactoring architecture can be either opportunistic or sometimes reactionary when there’s enough pain.

 
The Importance of Strategic Road Maps


As in any agile project, communication is key. This is especially true when you’re building and maintaining a data warehouse architecture.

One key component of an agile BI approach will be active management and communication of strategic architecture road maps. You start by performing an assessment and inventory of your data warehouse assets and capabilities. If the inventory is point A, then the vision of your data warehouse architecture will be point B. A good architecture road map shows snapshots of your expected architecture evolution for the next three to five years. The current year will have quarterly snapshots that (at a minimum) reflect your current planned project deliveries, years 2 through 5 will only offer an annual snapshot that shows which part to the architecture you plan to focus on.

At least once a year, preferably quarterly, formally update this road map and communicate it throughout your organization. Executive sponsors prefer this level of detail and progress tracking while gaining confidence that you have a well thought out plan. The annual review will also include the past year’s accomplishments and typically coincide with the budget planning process for the next year. While a physical architecture roadmap assists with the capital budget process, the logical data architecture deals more the BI deliverables and capabilities.

Finally, all aspects of your agile BI program will need to agile: the people, process, architecture, data, and technology. Agile architecture is keeping our natural data warehouse evolving while increasing value of the information platform and minimizing rework.

Logical Versus Physical Design in Data Warehouses

Your organization has decided to build a data warehouse. You have defined the business requirements and agreed upon the scope of your application, and created a conceptual design.

Now you need to translate your requirements into a system deliverable. To do so, you create the logical and physical design for the data warehouse. You then define:

• The specific data content
• Relationships within and between groups of data
• The system environment supporting your data warehouse
• The data transformations required
• The frequency with which data is refreshed

The logical design is more conceptual and abstract than the physical design. In the logical design, you look at the logical relationships among the objects. In the physical design, you look at the most effective way of storing and retrieving the objects as well as handling them from a transportation and backup/recovery perspective.

Orient your design toward the needs of the end users. End users typically want to perform analysis and look at aggregated data, rather than at individual transactions. However, end users might not know what they need until they see it. In addition, a well-planned design allows for growth and changes as the needs of users change and evolve.

By beginning with the logical design, you focus on the information requirements and save the implementation details for later.



Creating a Logical Design


A logical design is conceptual and abstract. You do not deal with the physical implementation details yet. You deal only with defining the types of information that you need.

One technique you can use to model your organization's logical information requirements is entity-relationship modeling. Entity-relationship modeling involves identifying the things of importance (entities), the properties of these things (attributes), and how they are related to one another (relationships).

The process of logical design involves arranging data into a series of logical relationships called entities and attributes. An entity represents a chunk of information. In relational databases, an entity often maps to a table. An attribute is a component of an entity that helps define the uniqueness of the entity. In relational databases, an attribute maps to a column.

To be sure that your data is consistent, you need to use unique identifiers. A unique identifier is something you add to tables so that you can differentiate between the same item when it appears in different places. In a physical design, this is usually a primary key.

While entity-relationship diagramming has traditionally been associated with highly normalized models such as OLTP applications, the technique is still useful for data warehouse design in the form of dimensional modeling. In dimensional modeling, instead of seeking to discover atomic units of information (such as entities and attributes) and all of the relationships between them, you identify which information belongs to a central fact table and which information belongs to its associated dimension tables. You identify business subjects or fields of data, define relationships between business subjects, and name the attributes for each subject.

Your logical design should result in (1) a set of entities and attributes corresponding to fact tables and dimension tables and (2) a model of operational data from your source into subject-oriented information in your target data warehouse schema.