BRIM™ Systems Development Life Cycle

BRIMÔ provides a technological foundation that should fundamentally change the way in which you build systems. There is nothing to prevent you from using the traditional Software Development Life Cycle (SDLC); however, building systems in this way will not take full advantage of what BRIMÔ has to offer in terms of rapid designing, building and testing capabilities.

Traditional systems development process is flawed

In addition to differences in the development life cycle, using BRIMÔ also means a completely different relationship between users and developers. In most cases, analysts gather requirements from users. The analysts then go build a system and then bring it back to the users. The users then need to “reverse engineer” their original requirements from the completed system. This process is inherently flawed. Using the BRIMÔ environment will avoid the all too common scenario where analysts meet with users, write down the requirements including paragraphs of business rules that must be supported by the system. Six months to a year later, when the system is delivered, the user wants to know where his/her original requirement is enforced in the new system. There is no easy way to find out if the rule is even being supported. Any sound systems development methodology must ensure some traceability from the original user requirements and business rules to the implemented system.

Business Rules are not equivalent to requirements. As an industry, we have mistakenly focused on requirements rather than business rules. Asking users for system requirements is implicitly asking the question “What do you want the system to do?” This effectively places the user in the role of system designer and allows the IT professional to partially abdicate his/her responsibility to understand the business. Designers routinely perform analysis with blinders by asking the questions:

· “What do you want to keep track of?”

· “How do these things relate?” (implicitly drawing the data model).

The problem is that users don’t understand what the answers to these questions mean in terms of the actual system design.

The problems described above do not exist in a BRIMÔ environment because all of the business rules are stored in a central repository, users can work alongside the analysts to enter rules into the system. As quickly as the rules are entered, iterations of the working system can be generated and users can provide immediate feedback about whether or not the system meets their requirements. This new way of building systems goes a long way towards bridging the large communication gap that has existed in the past between users and system analysts and designers.

Analysis Rules and Implementation Rules

In a BRIMÔ development environment, there is an important distinction between Analysis Rules and Implementation Rules.

Analysis rules include the users’ “business ramblings” expressed in sentences and paragraphs that have traditionally been gathered in the SDLC Analysis phase. They are relatively close to the way in which users think and talk. Examples of this type of rule include:

· “Purchase Orders (POs) over $50,000 must go through three levels of approval.”

· “Timesheets can only be approved by an employee’s supervisor or an HR Manager.”

These Analysis rules are neither precise nor complete because they are not directly implementable.

Implementation rules are the “translation” of these ramblings into a machine readable format. To represent the example rules above in BRIMÔ requires a UML data model with classes such as PO, PO Detail, Customer, and Employee with a process flow including all of the states that the PO goes through as part of the approval process. However, this is not the implementation itself of the business rule, but a precise specification of it as an Implementation rule. This Implementation rule can be used to generate a system that will support the rule. How this rule is actually implemented is a function of the generator that accesses the rule repository and builds the system.

BRIM SDLC

The following sections will describe the modifications to the traditional SDLC that should be made in a BRIMÔ development environment. This section references the CASE Application Development Method described in The Oracle Designer Handbook, 2^nd Edition (Koletzke & Dorsey, Oracle Press, 1998).

Phase 1: Strategy

The traditional Strategy phase will be the least impacted by using the BRIMÔ environment. The Strategy phase is still used to scope the project with the development team. Strategy-level data models can be entered into BRIMÔ to deliver a prototype system. As soon as the data model or high-level process flow has been articulated, BRIMÔ allows you to immediately generate and interact with the system. This will encourage more experimentation and truly interactive application development.

CAUTION: Just because you can go directly to implementation-level business rules and generate your system does not mean that you should abandon a structured methodology. Although BRIMÔ provides the capability to deliver early prototype systems, you should still prepare a Strategy Document (as described in The Oracle Designer Handbook) is still the appropriate foundation for a successful IT project.

Phase 2: Pre-Analysis

In the Pre-Analysis phase, the goals are to plan the analysis process and carefully scope the project. The deliverable for Pre-Analysis is the Analysis plan. Since the goal of Analysis is to gather and organize all of the substantive user requirements, when executed, the analysis plan should result in an understanding of what the business does and what kind of automated support it can use.

When working with BRIMÔ, it is also necessary at this point to set up some arbitrary rules to declare when Analysis is complete. There are several ways this can be done:

a) Once the new system has met or exceeded all functionality of the legacy system, Analysis can be declared complete

b) Time constraints – an arbitrary cutoff time can be declared for the first version of the system

c) Budget constraints – an arbitrary budget limit for system development can be set for the first version of the system.

However, it is important to remember that just because BRIMÔ allows you to quickly and easily support new or complex rules, this does not make you immune to “Analysis paralysis.” Whatever rules are agreed to in Pre-Analysis for declaring the first version of the system complete should be strictly adhered to. Successive versions of the system can follow fairly quickly to address any missing requirements or additional functionality.

Phase 3: Rules Analysis and Verification

In this phase, you need to take the following steps:

· Determine what all of the business rules are (Analysis Rules)

· Drill the business rules down to detailed lists and format them as Implementation Rules

· Enter them into the BRIMÔ tool and generate the system

· Verify that the selected rules are correct and adequate

The traditional logical Analysis process does not change in a BRIMÔ environment. It is still necessary to use source code, user interviews and the legacy system and existing documentation as sources of information for the new system. These source documents and interviews are used to determine the functionality of the legacy system as well as the new system requirements.

The goal of Analysis also remains the same in the BRIMÔ environment as it was in the traditional SDLC. By keeping the analysis focused on business rules, both analyst and user are forced to communicate about the business details and not about what the system should do, but what, from a business perspective, the system needs to support.

Many hundreds (if not thousands) of requirements will be gathered. There are several schools of thought about how to manage this information:

· OO use cases and scenarios

· Business policy

· Multiple functional subsets of requirements

Regardless of the method used, the result will be some form of categorization. There is no one “correct” way to do this. The best way will depend upon the designer’s background, expertise, the type and scope of the project and the experience level of the individuals involved.

Determining what level of detail is needed for these text-based paragraphs is a task ideally suited for the BRIMÔ. The PO and timesheet examples above are as detailed as necessary. The PO Analysis rules are easily mapped to Implementation rules by referencing the process flow associated with the PO to achieve both the implementation of the rule as well as traceability back to the Analysis rule.

The BRIMÔ Analysis process is different from the traditional SDLC Analysis where users play a passive role. Using BRIMÔ, users and analysts can work together to turn the Analysis Rules (requirements) into Implementation Rules. A version of the system is then quickly generated. Users can interact with it to actively verify that the Analysis rules have been correctly implemented.

Once Analysis is complete, a first version of the system is also complete since several rounds of modifications have already been performed to validate the rules.

Avoiding “Scope Creep”

The BRIM environment can support very detailed and sophisticated requirements including very complex workflows. Traditionally, systems either ignored complex workflows or enforced them through user training. Using BRIMÔ, you can add an additional state to a process flow very easily. This easy and inexpensive way of modifying the business rules can result in never ending “scope creep.” At what point can you move out of Analysis and begin the Test phase? There is no clear answer to this question.

Phase 4: Data Migration

As soon as the data model for the new system is stable, data migration should begin. Migrating to a BRIMÔ environment is no different than from any legacy system to a new environment. All of the standard ETL operations are used to map legacy table data to the new tables.

Dealing with current open business events can be challenging since objects must be migrated into specific BRIMÔ states.

Phase 5: Initial Testing

Once the data is migrated, the system should be put through an additional test phase to validate both the migration and implementation rules. Users are often not able to meaningfully evaluate a system until they can use and manipulate real data.

Phase 6: Application Building

BRIMÔ’s Object Builder provides a standard default system user interface comparable to generated applications in other products. For key applications, most systems will require some number of high-quality UI applications. These applications can be built very easily since almost all of the objects’ behavior is stored in the BRIMÔ rule repository. Hand-built applications (called “Object Viewers”) are usually simple master-detail applications modified to interact with the BRIMÔ rules repository.

Reports are also written at this point in the process. These should be created using flexible reporting techniques to take advantage of the BRIMÔ database’s object-oriented design. (For report design details, see the paper “Don’t Build 200 Reports! Build Just One” on the Dulcian website under Conference Papers and Presentations/Papers by topic/Reports.)

System documentation should be created during this phase. BRIMÔ repository reports will comprise the bulk of the system documentation. User documentation can be written based on the system documentation to explain how to use the system. Since the Object Builder is the primary UI, if other applications follow a consistent look and feel, the documentation should be fairly straightforward.

Phase 7: Testing

At this point, the business rules should already be well tested during both the Analysis and Data Migration phases. Final formal testing types should include:

· User acceptance testing

· Performance testing

· Integration testing

· Stress testing

· Backup & Recovery

Reports can also be useful in validating the correctness of the data model and data migration.

Phase 8: Training

BRIMÔ applies a consistent structure and rigor to the development process. This is particularly true with respect to process flow objects that will all have a similar user interface. Since users have been more involved at all phases of the BRIMÔ SDLC, less formal training should be necessary than in more traditional systems.

Phase 9: Deployment

Deployment of a BRIMÔ system is the same as for any system. The same decisions about whether to use a “big bang” deployment strategy or a phased deployment must be made. More information about deployment strategies can be found in The Oracle Designer Handbook – 2^nd Edition – Chapter 19.

Configuration Management

In most development environments, changes needed are identified and grouped before being rolled forward into the production environment. BRIMÔ easily supports this process since the entire architecture is designed to handle ever-changing business rules.

(See the Configuration Management document for more details.)

Conclusions

Building systems in a BRIMÔ environment is similar to the traditional systems development process in the beginning Strategy and Pre-Analysis phases and the end Testing/Training/Deployment phases. It is the middle portion of detailed Analysis, Design and Development where BRIMÔ replaces all three phases with a single Rules Analysis and Verification phase. This is where BRIMÔ’s largest impact and time-saving advantages can be realized. Rather than having long cycle times between requirements gathering and deployment, the time required for these steps is greatly reduced. This is the key to why BRIMÔ systems can be built much more quickly and easily than systems in a traditional environment.