Class-Based Reengineering (CBR)
Class-Based Reengineering focuses on structurally transforming the information systems organization into one that is better equipped to implement object technology and business process innovation. The basic premise of class-based reengineering is that organizational boundaries between application teams obstruct effective development of enterprise-level classes and reusable object components. The objective of class-based reengineering is to influence information systems management to decrease reliance on the functional organization and instead begin to develop organizational realignments based on classes. By structurally reflecting the object model of the business, a class-based organization is uniquely positioned to rapidly support cross-functional processes and fulfill the strategic objectives of the firm. The 'strategic object model' is the blueprint for managing the transformation to a class-based organization. This article identifies the basic philosophy of class-based reengineering and suggests implementation strategies for organizations seeking to restructure themselves to maximize the benefits of object technology.
Functional Organization
The 'functional organization' is the dominant form of organizational structure governing information systems organizations today. It is philosophically based upon the functional paradigm. The functional paradigm suggests that the best way to manage a complex business function is to logically subdivide it into a set of lower level functions that can individually be more easily controlled. Division of labor is based upon a functional decomposition of the organization's major business functions into functional application teams. A hierarchical management structure representing a wider level of functionality is utilized to manage and control the application teams. (Figure 1).
Functional applications have evolved as semi-autonomous data processing entities with their own distinct user interfaces, business processes, databases, reporting mechanisms and uses of technology. They are popular because they are well-positioned to provide concise and effective tracking of tasks, as well as control of human resources, systems resources and capital resources. There is a direct line of accountability between the business unit and the functional application responsible for implementing the business requirements.
High Costs
While functional applications are highly prevalent in IS organizations, the expense of such applications is nevertheless relatively high. This is due to the high overhead cost of developing and testing customized code. The organization must bear the costs of training and retaining systems personnel possessing the specialized technical and business skills needed to support the requirements of the sponsoring business unit. The time to market for system-enabled products is long, and the backlog of change requests is often high.
High Duplication
Data structures and processing functions constructed by one application often duplicate work performed by other application teams. A bank, for example, might replicate customer, account, product, and transaction entities across many applications. Due to the high number of redundant data stores and processes that proliferate across functional applications, the organization ends up paying for the same thing over and over again. (Figure 2).
Object-oriented Antidote
Object technology with its promise of reusability, has been promoted as the antidote to the problem of the high cost of systems development and testing. Significant benefits from object technology can best be realized when there is a high frequency of object reuse and a commensurate decline in the development of redundant application code. A major objective of object technology is to free the development team from rebuilding code that has already been developed elsewhere in the organization. The expectation is that through object reuse, development and testing costs are reduced, and the application team can devote additional quality time to develop the custom code required for product differentiation and competitive advantage.
Marginal Benefits
However, object oriented technology deployed within functional application teams may only produce marginal benefits. One reason for this is that application teams are required to construct systems deliverables that pertain fundamentally to their own immediate line of business. The result of such a concentrated focus is object oriented code that is only reusable within each individual functional application itself. The problem is magnified as this process is repeated by other functional application teams. The paradox is that redundant application-centric procedural code is replaced with redundant application-centric object-oriented code. The goal of constructing a unified, integrated, enterprise-wide repository of reusable objects becomes unattainable in this scenario. Instead, multiple incompatible instances of classes are built by disconnected functional application teams. The net result is an inventory of classes that are not reusable across applications.
Functional Boundaries
It can be a monumental, if not impossible, task to develop generic classes and reusable components from within a functional organization. By virtue of it's hierarchical application structure, the functional organization is structurally handicapped from facilitating communication across organizational boundaries to other functional organizations. It is difficult for direct communication to occur between application teams when they are positioned at the bases of different functional and political hierarchies within the organization. Open exchange of ideas, which is a pre-requisite for constructing and utilizing re-usable components, can only occur when structural boundaries between IS divisions, departments, and application teams are transcended.
Guerrilla Reusability Is Ineffective
Among proponents of object technology, there is intellectual momentum to maximize class reusability. The logical attraction to class reusability encourages object-oriented developers from one functional application to share class libraries with developers from other functional applications. This form of 'guerrilla reusability' often arises as an informal bottom-up process. While positive in intention, guerrilla reusability can only be effective on a small scale and therefore will only yield minimal benefits. Enterprise-wide benefits will come when the process of reusing classes is formalized as an objective of a management sanctioned strategic plan that embraces class-based reengineering.
A second premise of class-based reengineering is that classes can span many functional business units within an organization. A 'customer class', for example, can traverse many different organizational units. Because classes can be cross-functional, they are well suited to optimize the deployment of business process innovation. In order to foster a new business process, It is easier to orchestrate collaborations between class components than it is to establish new interfaces between functional applications.
A third premise of class-based reengineering is that classes are a corporate resource to be managed and controlled. Ownership of the data and functionality encapsulated within a class is delegated to a class-team. In a class-based organization, classes are homogeneous. Classes are not fragmented or scattered across the organization as is common in functional organizations where multiple applications house their own versions of the same class. Centralized control over a class does not mean that it's internal data must also be centralized. Internally, data can be distributed across the organization's network. What is centralized is the ownership of the class, and the management of it's operations, it's interfaces and it's implementations.
A fourth premise of class-based reengineering is that redundancies in information management can be consolidated through the process of 'class refinement' into a reduced set of more powerful reusable classes. If one were to analyze a functional organization's current portfolio of information systems it would become apparent that a large number of redundancies (processes, data, and even objects) would be identified. Class refinement not only minimizes redundancy, reduces systems development and testing costs, but it also introduces new functionality to a greater set of clients than was possible before. As a result of class refinement and the introduction of new reusable classes, the power of information processing within the organization is magnified.
A fifth premise of class-based reengineering is that information systems tend to reflect the firm's organizational structure. Information processing generally extends no further than the organizational boundaries of the application team. Sharing of code and executables rarely occurs outside of the functional application structure. This is not so much due to technical constraints as it is due to organizational constraints. Class-based reengineering forces greater sharing by reorganizing teams by class and not by function.
A sixth and vital premise of class-based reengineering is that the information systems organization must reflect the object model of the business. By representing the major class components of the organization, teams can specialize in class definition, management, construction and innovation. By realigning systems personnel into teams that focus on developing classes rather than developing self-contained functional applications, enterprise-wide reusable objects can be effectively constructed.
Strategic Planning for Class-Based Reengineering
A strategic plan for class-based reengineering requires the accomplishment of four major deliverables. The 'baseline object model' identifies where the organization currently 'is' from an object-oriented perspective. The 'strategic object model' identifies where the organization wants to be from an object-oriented perspective. The 'class-process matrix' draws from the strategic object model to correlate which classes are utilized to support the requirements of a business process. The 'class-based organization structure' identifies how the organization is to be restructured in order to achieve it's strategic objectives.
The Baseline Object Model
The first step in the transition towards a class-based organization is to develop a baseline object model of the business. The baseline object model is a visualization of the organization's current information systems from an object oriented perspective. Although a target application may really be based upon non-object oriented procedural technology, the application can still be analyzed in terms of it's 'implied' classes. What this exercise exposes is a concise object-oriented representation of the major process and data components used by the application. By using an object-oriented perspective to illustrate what already exists, it is easier to identify class redundancies. Italso becomes easier to target opportunities for class refinement.
The Strategic Object Model
The strategic object model is an evolving object model of the internal and external environment of the enterprise. The internal environment of the organization includes the processes and resources that reside within the boundaries of the enterprise. One could view the firm's organizational structure, human resources, business services and operations, facilities, capital assets etc. as objects. The external environment focuses on the organization's suppliers, customers, competitors and regulators as objects . The strategic object model represents a high level class-based context model of the enterprise's world-view. (Figure 3). The model illustrates how these classes interact and collaborate with each other to perform the enterprise's business. Object administration and the strategic planning unit collaborate with senior management to define the strategic object model. The strategic object model must echo as well as influence the organization's strategic business plan.
The strategic object model defines the roles and responsibilities of the organization's principal set of classes. These classes represent the organization's internal and external environments. They represent how the business operates. They are the classes that exert significant influence over the business. They also highlight opportunities to attain competitive advantage. The strategic object model should expose redundancies and weaknesses in the organization's current functional structure. By constructing a network of classes that interact with one another, the strategic object model identifies clusters of classes that collectively fulfill the requirements of business processes.
Class Categories Classes that appear in the strategic object model are categorized into either core classes, business-process classes or utility classes.
Core Classes
Core classes are the essential building blocks of the business, without which the business cannot function. They include the business's most fundamental components such as customer, product, account, transaction etc. Although core classes have public interfaces they primarily advertise their services for use within the organization's internal environment. Core classes make up the operating system of the business. To use a mechanical metaphor, core classes make up the organization's engine.
Business-Process Classes
Business-process classes represent the organization's major set of business services and business operations. It is through these classes that the organization's business is generated and expanded. Business-process classes interact with the external environment to conduct the firm's business. Business-process classes request services from core and utility classes in order to fulfill business objectives. Customer service, mortgage banking, investment banking, retail deposit banking are examples of business-process classes for a banking institution. They frequently include user-interfaces and high-level business processing logic. Like any class, a business process class may be sub-classed into more granular components. Business-process classes are the operators or drivers of the organization's engine.
Utility Classes
Utility classes provide generic services to both business-process and core classes. Utility classes provide services that are generally outside of the domain of the organization's intrinsic business. They typically provide auxiliary services such as logging, auditing, workflow management, security, as well as common infra-structure services such as printing, fax, encryption, and mail. Core and business-process classes can inherit interfaces from utility classes. Utility classes provide the services that the organization requires in order to function efficiently and avoid breakdown. Utility classes make up the lubrication system of the organization.
Business Partner Participation
Business partners are representatives from the business units whose operations are supported by the classes defined in the strategic object model. The essential participation of business partners gives the class designers the business and political justification that is needed to design and develop reusable classes. Business partners also certify that the correct functionality is represented by the class.
Business Process Teams
Class-based reengineering works well within the context of an overall organizational commitment to business process reengineering. Business process teams can play a decisive role in assisting in the design of reusable classes. It is important for members of business process teams to participate in the definition of classes, so that classes can be designed to fulfill the operational requirements of the business process. The business process teams adds a cross-functional dimension to the definition of the class. The collective participation of business process teams maximizes the potential for class reusability and encourages ideas for strategic advancement. The business process team can super-animate the class to perform new functions in order to fulfill their vision of process innovation.
Class-process Matrix
A class-process matrix is a chart that represents the intersection points between classes and business processes. (Figure 4). Object administration updates the class-process matrix to document the multiple processes supported by a class, as well as to document the set of all classes required by a business process.
Class Associations
Functional applications with their monolithic closed architectures are obsolete in a class-based organization. In the class-based organization, there are instead class associations. A class association is a grouping of classes that collaborate with one another to fulfill a business process. The class association may contain one or more business-process classes, core classes and utility classes. Many of the same classes that participate in one association may also participate in other associations. (Figure 5). It is through this kind of reusability that the organization begins to experience dramatic benefits from object technology. From a technical perspective, class associations can be developed using many current object technologies, however, CORBA-compliant distributed object technologies offers the most robust and comprehensive frameworks for implementing successful class associations.
New Organizational Structure
Object technology is a paradigm shift. Major paradigm shifts are not only limited to changes in thought but are also accompanied by structural changes in organizations. For the object paradigm to become dominant, major changes must be made to the structure of traditional information systems organizations. A new organizational structure is needed that is better equipped to fulfill the objectives of the object-oriented paradigm. This new organizational structure must overcome the limitations of the functional organization. It must be capable of spanning multiple high-level business processes. In addition, it must be able to construct reusable class components that support the collective needs of many business units. Finally, it must provide value added services by horizontally bridging the organizational boundaries that restrict conjoint development.
The Class-based Organization
Class-based reengineering proposes that the information systems organization should be organized around classes. Classes are not merely abstractions for code development, they are also a means to organize labor. The class-based organization is essentially a representation of the class hierarchy of the business. Building classes to fulfill business objectives is the central focus of the class-based organization. The boundaries of each class might potentially extend across the entire organizational spectrum. The class is a global concept that is not just pertinent to one application, department, or division, but rather to the enterprise as a whole. The class-based organization is committed to the principle that classes are designed and constructed with a total enterprise orientation. Class fragmentation is inherently controlled and resisted in a class-based organization.
Figure 6 illustrates a view of a centralized class-based information systems organization. Class-based organizations can also co-exist in decentralized organizations. In a decentralized class-based organization, classes are developed by individual business units. In this scenario, the interfaces to the classes are still controlled and managed by object administration and the division of labor continues along class boundaries.
Human Resources Impact
From a human resources point of view, a class-based organization should be flatter than a functional organization. By transitioning to class teams, fewer personnel can demonstrate greater productivity than is normally achievable by functional application teams. As functional application teams are replaced by class teams, personnel previously dedicated to supporting the redundancies of the functional application would become available for reassignment. Class-based reengineering thus attempts to generate greater organizational efficiency.
Class Teams
In the class-based organization, development teams are no longer organized according to a functional decomposition of the business, they are instead organized by class categories. Class teams structurally reflect the class hierarchy of the business. A class is thus managed by a team. The theory is that team members, belonging to a common development group, will more effectively construct and maintain the entire class. The class team is thus the alternative to the policy of delegating slices of a class to different functional applications for development. In fact, the separation from the functional application prevents biases and exception logic from being introduced into the class design, which could diminish it's reusability. The class team is responsible for developing all of the different physical implementations for a class. This may include developing the class across different languages and across heterogeneous platforms.
Class-team Categories
Like classes, development teams are categorized into process class teams, core class teams, and utility class teams. Process class teams access services from reusable class components constructed by core class teams and utility class teams. Process class teams develop user interface classes, as well as invoke requests to core and utility classes. The goal of the class-based application is to construct the class components which are represented in the strategic object model. For example, a customer service class is a process-oriented class that might perform a balance inquiry operation against a collection of core account classes contained by a core customer class object. An audit utility class is used to log the details of the transaction.
Transitioning to a Class-based Organization
Class-based reengineering promotes change. Resistance to change can be expected not only due to fear of organizational change but also due to fear of not grasping a new paradigm. The first challenge for management is to effectively communicate the vision and benefits of class-based reengineering in order to promote a solid conceptual understanding, reduce resistance and inspire excitement. The second challenge is in selecting the most suitable candidate applications for the firm's initial class-based reengineering effort. Consolidating classes from two or three related applications within the same department would be a good starting point. A bank, for example, might attempt to reengineer residential lending with consumer lending. To increase the odds of success experts knowledgeable in object technology should be used to mentor class team members. A rollout strategy must be published that schedules class-based reengineering efforts across a wider path of application teams and departments.
Conclusion
Class-based reengineering offers organizations a plan for achieving a breakthrough towards developing reusable class components. Perhaps the most important feature of class-based reengineering is that it forces organizations to rise above the atomic concerns of information processing found within functional applications to instead grapple with the major class categories that are fundamental to their business such as what is a customer, what is a business service, etc. By reengineering the structure of the information systems organization to reflect classes, the enterprise is required to answer it's most existential of issues. It is through this process alone that the organization is able to reshape itself and truly use information systems as a strategic weapon.
Copyright Technium, Inc. 1995
All Rights Reserved