Business Process Reengineering

Business Process Reengineering

Business process reengineering (BPR) is one of the more popular methodologies used to redesign existing applications. A more formal definition of BPR is “a requirement to study fundamental business processes, independent of organization units and information systems support, to determine if the underlying business processes can be significantly streamlined and improved.”28 BPR is not just rebuilding the existing applications for the sake of applying new technology to older systems, but also an event that allows for the application of new procedures designed around the OO paradigm. Remember, it is the OO paradigm that focuses on the essential components that were outlined in Chapter 9. The essential components first require the establishment of the core business requirements and then the mapping of the functionality of the organization or business unit to these components.

You might recall that existing applications were referred to as legacy systems in Chapter 3. Many chief information officers (CIOs) today are confronted with a corporate mission to reengineer their existing applications and apply a more sophisticated and structured approach to developing what is known as the enterprise system. The enterprise system is composed of one common data repository for all of the organization’s data. The typical enterprise configuration includes the OO paradigm and the client/server model that was developed in Chapter 9 and is repeated here as Figure 13.1.

The mission of BPR is to take an existing system, which is typically based on older technology and developed on the basis discussed in Chapter 9 (where the analyst is on the outside looking in), and reengineer it into one integrated system. Much has been written about the approaches or methodologies to use when applying BPR, especially by Ivar Jacobson.29 The focus of this book is to provide direction from a practitioner’s perspective, that is, something that can realistically be applied within the typical resources and constraints that exist in most IS organizations of today.

process reengineering using object technology.

Figure 13.1 Client/server three-tiered architecture.

Analyzing Legacy Systems

The first step to applying successful BPR is to develop an approach to defining the existing system and extracting its existing data elements and applications. Once again, this is similar to the process described in Chapter 3 in that the data needs to be captured into the data repository and the applications need to be defined and compared to a new model based on essential components. Our assumption in this section is that the legacy system resides on an IBM mainframe computer. The data is stored in a VSAM format (non-database files) and the applications have been developed in COBOL. There are no central libraries or repositories of data or programs.

Data Elements

The analyst team will need to design conversion programs that will access the data files and place them in a data repository. The simplest approach is to use a repository from a CASE product. Once this has been accomplished, the analyst can utilize a reverse engineering tool to access the converted data based on the same procedures outlined in Chapter 3. Once all the data elements are loaded, the more rigorous process of identifying duplicate elements becomes the major effort. Duplicate elements may take on different forms. The most obvious is the same element with the same name and attributes. Another type is the same element name, but with different attributes. The third type, and the most challenging, is the duplicate elements that have different names and different attributes. This third type can be related to our discussion about combining user views (see Chapter 4). In any event, users and analysts will need to begin the laborious process of taking each element and building a data repository.

Applications

Application documentation is more problematic but again resembles the procedures followed in Chapter 3. This means that each existing application must be flowed and included as part of a new reengineered processes. Although this procedure may sound straightforward, it is not. BPR typically involves a methodology called Business Area Analysis (BAA). The purpose of BAA is to:

• establish various business areas that make up the enterprise.

• break down the business areas to their required data and process portions.

• reengineer the new and old requirements of each business area,

• develop requirements that provide an OO perspective of each business area, meaning that there is no need to map its needs to the existing physical organization structure,

• define the links that create relationships among all of the business areas.

A business area should be developed in the same manner as depicted in Chapter 9, where we established the essential components of a bank. Each component is a business area that needs to be reengineered into its equivalent OO and client/server enterprise system. Therefore, each essential component must be functionally decomposed to its reusable parts.

Combining Structured and Object Techniques

Once the essential components or business areas have been completed and agreed to by the user community, it is time to develop the actual architecture of the new reengineered system. What modeling tools should we use? The answer is that we should be ready to use all of them when required. Figure 13.2 is a schematic of the reengineering process within a business area.

Like OO, BPR also uses the object concept to develop cohesive and reusable processes. We use the example from Chapter 9 to demonstrate how this maps to business areas. Once the business areas are defined, the structured tools should

Figure 13.2 BPR modeling using the essential components of a bank.

be used to define all data and processes. BPR supports the concept that the data for a business area should be determined before the processes. You may recall that the same data represented an excellent method for creating cohesive modules. By using the same data, functional primitive DFDs and STDs can be mapped to their appropriate business area.

Logical data modeling and the ERD will need to be completed prior to creating the permanent objects and classes that belong to each business area. Normalization must be applied to the required entities, which will not only have the legacy data elements but also those added as part of the reengineering analysis process.

Prior to mapping the processes and data to their logical objects, the analyst can use another tool to assist in the reconciliation that all data and processes have been found. The tool is called an association matrix or a CRUD diagram.

“CRUD” stands for the four functions that can be performed on any entity: create, read, update or delete (archive). The importance of the CRUD diagram is that it ensures:

• that an object has complete control over its data,

• that a data file is accessed by at least one process, and

• that processes are accessing data.

The CRUD matrix in Figure 13.3 tells us a lot about the status and activities of our business area data and processes:

• Only the Items entity has enough component processes to control its objects data, that is, by spelling CRUD its processes have the minimum capabilities to control the cycle of any data element. Although this does not ensure that processes are not missing, it is a good indicator that the analysis has covered the life cycle of an entity.

• The Expense Category is not accessed by any process. This means that

we have a file that the system is not using. This is an excellent indicator that processes are missing.

• The Customer, Expense Category and Salesperson data are created and deleted by some other processes or business area. This could be a situation where the physical location of a business function is not where it logically should be processing. The analyst should look for the missing processes to complete the spelling of CRUD before finalizing both the processes and data of any business area.

Even if BPR is not used, the CRUD diagram is an excellent tool to use to determine the processes and data needed for an object. Once the CRUD diagram is finalized, the objects and classes can be created, as Figure 13.4 displays.

It is important to recognize that many of the objects that are developed during BPR may become reusable components of other business area classes. If there

Figure 13.3 Sample CRUD diagram.

Figure 13.4 Business area component objects and diagrams.

are additions to an object as a result of reviewing a new business area, then the object’s data and methods may need to be updated. The best approach to tracking these objects is through an integrated CASE tool, although any level of automation can be feasible.

Dealing with End Users

When applying BPR, analysts need to formulate a plan for how users and user groups will be interviewed. Most important, since reengineering implies change, change means discussions that must lead to decisions. Coordination of these decisions is critical, and it can get out of hand quickly. For this reason the analyst should attempt to organize BPR using multiple JAD sessions. The sessions should be focused first on each individual business area. Prior to actually holding the session, analysts and facilitators should educate users on the techniques and reasons for BPR. Analysts should not be afraid to show users the business area schematic and explain the concepts of essential components and how they eventually can become reusable objects. This means that there may be a need to hold a one-day training session for the users who will be involved in the JADs. This suggestion is consistent with the concept of having users prepared before they attend a meeting.

JAD sessions should be organized to have session leaders who can provide walkthroughs of the existing functions. While these walkthroughs take place, the adjustments and missing functionalities can be added to the business area. The issues concerning the selection of key personnel as they were outlined in Chapter 1 are extremely important, especially when selecting decision makers. Because of the volume of information being discussed, it is advisable to have more than one scribe available. This minimizes the risk of not capturing important business rules.

After each business area is completed, the links to the other business components must be handled. These should also take place via JADs and typically use the session leaders as attendees. Session leaders tend to have enough information at this point from the JAD sessions to determine the necessary links for each business area.

The use of prototypes for each JAD is highly recommended because it will provide the best vehicle to get agreement on the new system. This suggests that an integrated CASE product is almost a necessity for creating a successful BPR project.

Information Systems Issues

BPR is implemented on existing systems. Existing systems have IT staffs and constraints that must be addressed as part of the process. Since the current view of BPR is to create an open systems client/server enterprise system, the physical requirements of the network are critical during analysis. Remember, RAD means the combining of analysis, design and development into multiple iterative steps. In order to take the objects and classes developed from the JAD sessions, the analyst must start breaking up the data and methods of the classes into its related client and server functions. You may recall that if the client and server processing portions of an object must reside on separate hardware components then the object/class must be separated or further decomposed into separate physical modules (see Figure 13.5).

We have emphasized the importance of analysts being involved with the network design for client/server systems. BPR thus requires that the network design be completed as soon as possible and ideally before analysis starts. This

Figure 13.5 Client/server hybrid model.

will be difficult since many of the network decisions may be altered depending on how the objects become distributed across the network. In addition, the back- end database stored procedures (business rules, triggers, etc.) and middleware software components must be defined while the analysis specification is being finalized.

IS personnel must also be heavily involved in the JAD sessions to clarify questions about the existing system processes. This will involve discussions about the amount of data processed, as well as the difficulty or ease of getting additional information from the suggestions brought up during the JADs. IS can also disclose the details of the equipment choices and how these may affect the requirements being discussed. Such input may enable quicker decisions based on predetermined IS constraints.

Finally, IS will be required to establish the information about the existing data and processes. They will most likely be responsible for the conversion of the data as well as for clarifying the meaning of many of the data elements in question. You may assume that many of the legacy data element definitions will be unknown, and as a result analysts and programmers will be spending time together figuring out what such elements do in the system. Existing process review means looking at the current application programs and how they function in the system. Most of this work will be required from IS programmers and legacy designers (if they are still around!). Since our assumption was that the existing system was developed under COBOL, there will be a more difficult mapping of how a 3GL (third generation language30) is designed as opposed to today’s 4GL (fourth generation language31) products.

System Development Life Cycle (SDLC)

BPR changes the steps in the typical IS SDLC. The traditional SDLC is based on the waterfall approach as was shown in Chapter 1 and is repeated here as Figure 13.6.

The problems with the waterfall approach are that it is unrealistic (as discussed in Chapter 1) and that it does not conform to the requirements of the OO life cycle. Therefore, IS must modify its SDLC to conform to the OO and client/server needs of BPR. The OO client/server life cycle resembles a spiral as shown in Figure 13.7.

The spiral life cycle reflects a much larger allocation of time spent on design than in the traditional life cycle, because much of the development time is spent designing the objects for product reuse. Although this may appear unduly time- consuming, there is a heavy payback in BPR if it is done correctly. Remember that the spiral life cycle is applied to the development of each object since it is a cohesive component within itself. The more reusable the object, the more spiral the effort becomes with a particular emphasis on the analysis/design phase.

Figure 13.6 The classic waterfall SDLC, showing each phase dependent on the completion of the previous one.

directly with database systems and contain simpler program instructions than its predecessor languages.

Figure 13.7 Object-oriented software life cycle.

Pilot Applications

Many analysts opt to have a pilot application as part of the BPR effort. The purpose of the pilot is to get users excited about the benefits of creating the new system. Because an actual application is developed, IS must be involved to ensure the pilot is successful. How can success be evaluated? The first real decision in a pilot is to select an existing application that is not working favorably and one that can demonstrate enough advantages of the OO GUI and client/server environment to pique the interest of users. Below is a suggested strategy:

• Focus on an application that can demonstrate the flexibility of the GUI front end.

• Select an application that accesses existing corporate data to show the

users how easily the data can be reached. Analysts should avoid an application that gets involved with massive updates or large data queries, as this is inviting an unexpected delay in processing. Such exercises tend to involve much study and experience with the corporate network of information, and this expertise may not be available.

• Select an application that has a relatively short development time when

using a GUI product. Do not try an application which might be more involved when using a client/server model.

The pilot application not only has the potential to generate more interest, but it also allows users to be more creative and understanding of the requirements of BPR.

Downsizing System Components

After the business areas and interfaces among them have been completed, the analyst and development must decide on a strategy for implementation. To attempt to convert an entire enterprise level system in one project is very dangerous and very unlikely to succeed. The user community also needs to be involved with this decision since many business units can convert only at certain times of the year due to various seasonal business requirements. Therefore, the analyst must plan to migrate applications in pieces. It is only logical to do this migration by business area and to develop temporary legacy links back to the main system. Most organizations are doing just this by purchasing open systems hardware and moving complete self-contained business areas independently onto the new platforms (see Figure 13.8).

As each business area is converted to the open systems architecture, the temporary legacy links will be deleted and incorporated in the new system.

Transactions Versus Data Warehousing

Our sample system is categorized as a transaction-based operation, that is, the system was designed to maximize its performance based on the processing of transactions. This type of systems must perform under the stress of many users

Figure 13.8 Legacy links of a business area.

who are using the system for production purposes. The limit of these systems is that they do not provide the end-user with on-line data comparisons and what-if analysis in a productive and robust environment. Such systems were designed in the early 1980s and were called decision support systems (DSS). Today’s robust software goes even further than the awkward DSS systems, and users want the same level of flexibility with their enterprise solutions. The problem is simple: You cannot maximize your transactions performance while maximizing your DSS functionality. The result is many client/server systems have had trouble performing at the same level as the legacy systems. SQL-based queries that are issued during peak time enterprise processing can cause significant slow-down in processing. In most cases such delays are simply unacceptable. In fact, GUI applications will never outperform VSAM transaction-based mainframe systems. This sounds like a disappointing state of affairs for users. The remedy is to separate the transaction processing from the DSS functionality and improve transaction processing to an acceptable user level. This is accomplished by creating a data warehouse environment (see Figure 13.9). A data warehouse is an archive of the database off-loaded usually to a separate machine to provide DSS capabilities to those that need to query information.

The problem with data warehousing is the currency of the data, since off- loaded information is typically not performed real-time. Therefore, users must agree to use “old” data. Many organizations have provided data warehousing capabilities within hours of the input or update of information. Nevertheless,

Figure 13.9 Transaction/data warehouse BPR solution.

data warehousing can work only if the user community can settle on aged data that they cannot change. There are products such as SAS that provide specific tools to create data warehouse databases. Often the data is not fully normalized because the user cannot change the information. This results in a more efficient and accessible database because the information is stored in a flatter format (fewer database files). Almost every database manufacturer will be providing data warehouse capabilities in their next release. The analyst must be involved in determining which applications (usually reporting and inquiry operations) are candidates for the warehouse function. Analysts and IS personnel must take care in explaining the role of the data warehouse to the users so that they can use it effectively.

Problems and Exercises

1. Explain the objectives of BPR.

2. How is BPR consistent with the object and client/server models.

3. What is a business area?

4. Explain the relationship between BPR and structured tools.

5. What is a CRUD diagram?

6. How should BPR be introduced to users and IT personnel?

7. What is the SDLC? Why is it called a waterfall approach?

8. Compare the SDLC with the OOLC.

9. What is the significance of the spiral approach and how does it support the development of reusable objects?

10. Describe the procedures to implement a pilot application. Why is this so important in BPR?

11. Describe the philosophy of reengineering an enterprise system.

12. What is the difference between a transaction database and a data warehouse?