Communications of the ACM

Communications of the ACM

Enterprise Computing Environments and Cost Assessment

By Sudip Bhattacharjee, R. Ramesh
Communications of the ACM, October 2000, Vol. 43 No. 10, Pages 74-82
10.1145/352183.352208
Comments

The object-oriented (OO) computing framework we present here helps design and develop the complex, multifunction software systems used in enterprises' core and supporting business processes. A related cost-assessment model evaluates the framework's planning and implementation processes.

The value of OO design techniques in building appropriate, efficient, and inexpensive applications for enterprisewide deployment is widely recognized [7]. But views of OO frameworks range from structures of classes of cooperating objects that provide reusable basic designs for similar applications to high-level modules that result directly in specific applications for a particular domain [3]. We take a unifying view in our approach and propose the OO framework to help design business computing environments. It enables cost-effective integration of heterogeneous hardware platforms, along with the applications that enable, drive, and support mission-critical business processes and their users in dispersed locations accessing diverse types of data to carry out mission-critical business functions [1]. Although we modeled and developed the framework for a three-tier client/server architecture [11], it can be modified to suit any specific organizational requirements and business context.

Assessing the cost of planning and maintaining an OO framework is of great interest to practically any organization's senior IT management. Important benefits include:

• Support for performance management;
• Insight and understanding of information resource utilization for business operations, as well as trend analysis of these resources;
• Improved proactive decision support for these and other functions;
• Help for garnering support and financing from top management for ongoing and planned improvement projects; and
• Help in determining process improvements via the Software Engineering Institute Capability Maturity Model [8] to assess the maturity of an organization's software processes and improve process maturity and cost and system management.

Some cost-of-ownership evaluation templates from notable research firms like the Gartner Group and IBM are used by corporate IT managers to estimate the life-cycle costs of owning and operating workstations. However, most of these measures do not account for development, integration, training, maintenance, and productivity improvement of and from business applications. Our cost assessment model helps estimate the costs of planning, developing, maintaining, and improving an OO business-computing framework. IT managers can develop templates they can tailor to specific requirements and use as decision-support tools for assessing the cost of developing and maintaining enterprisewide OO frameworks.

Back to Top

OO Modeling Framework for Enterprise Computing

Developing an organization's business computing framework includes overall planning of information and infrastructure requirements, along with detailed planning of the framework elements and their properties, functions, and interactions.

Business information requirements planning. An enterprise's major information services strategy frequently involves satisfying the following general information architectures [11]:

• Query/response. A query/ response architecture, which can be used for ad-hoc querying and for producing reports, is widely used in legacy client/server and Internet environments where each query request is treated individually.
• Conversational. A conversational architecture, such as those in executive information systems (drill down) and decision support systems, is used by managers and strategic planners. Interactions between the client and the server take place in dialogue mode and are context dependent.
• Queued-message. A queued-message architecture is usually used for routine transaction processing and producing reports.

To satisfy these requirements and develop an OO enterprise computing framework, our framework models an organization's business processes as an OO structure of hierarchical classes. It assumes an initial number of business processes for an initial framework. Identifying the entities in this framework depends on a particular organization's functions and regulations (and is beyond the scope of this article).

A business-computing framework consists of a set of business-process classes that may in turn consist of business-process subclasses that may in turn contain other subclasses. An elemental business-process class consists of two main entity classes: User and Task (see Figure 1). The attributes of a business-process class may be simple, such as a data update, or complex, such as a workflow. The Task class is in turn an aggregation of three other elemental classes: Business Logic, Input Data, and Output Data, as in the figure. The Business Logic class contains attributes and methods for modeling an elementary business object, such as a simple debit process or an authorization process [2]. Various instances of the Business Logic class may occur in different Task classes, depending on process definition and requirements. Careful analysis and modeling of processes at this stage greatly simplifies the subsequent building of the framework.

There is one-to-one mapping between the classes of a business process hierarchy and the major entities of an abstract client/server-based infrastructure hierarchy. Figure 1 shows the mapping and formalization of business-process classes to the entities of a client/server system. A business-process class may also contain other subclasses, while the elementary business-process subclasses consist of the User and Task classes. Table 1 shows the mapping from the real to the abstract hierarchies. Therefore, a business process can be modeled using the three major classes: User, Application System, and Data. The relative independence of these classes with respect to attributes, methods, and physical location means significant flexibility in the design, development, and maintenance of the various parts of the OO framework.

Infrastructure requirements. Figure 2 shows a high-level view of the three major classes of abstract objects and their interactions in an enterprise. For example, the User class, which is associated with one or more business processes, may be physically dispersed in a number of geographical areas. The Application System class, which is accessed by the User class, may be associated with one or more business processes; the entities that belong to it may be distributed geographically and hosted throughout the enterprise. The Application System class accesses the Data class, whose entities may likewise be dispersed throughout the organization.

A three-tier computing model illustrates the modeling issues in infrastructure requirements planning and in designing the initial computing framework. This most general form of computing modeling can be customized into other models, depending on an enterprise's special requirements. For instance, upgrading an existing architecture using this three-tier computing approach is the functional equivalent of building a new IS environment. Upgrading may involve additional and differential costs for integrating the existing infrastructure, including hardware, applications, data distribution, and user interfaces, into the client/server architecture. The cost assessment model described in the following sections helps identify and calculate these costs.

Back to Top

Design Templates

Each of the major abstract classes—User, Application System, and Data—may hierarchically contain one or more subclasses. For example, a User class may contain the subclasses Manager, Administrator, and Clerk as elemental classes representing an organization's various user types. Table 2 shows an example of classes, subclasses, and object attributes of the User and Application System classes related to the object names in Figure 1.

Similarly, the Data class is an aggregation of the various subclasses of data types an organization deals with, including databases, documents, and multimedia files; the attributes of these specific Data classes depend on the type and description of the data being stored by the organization.

To aid the integration and interoperability of the major framework elements, the framework incorporates an Interface class. This class helps encapsulate the attributes and methods of the three major classes, such that the minor modifications, authorizations, and logic required for accessing functions and attribute values of one object by another object can be embedded and executed through it. The Interface class objects link the object instances of the other classes, such that the parameters passed between objects are handled through the Interface class objects. This Link class makes it easier to modify the linking and enabling of different objects so they interact with one another without changing the implemented methods in the objects themselves. The result is that different business functions are achieved more readily, while greater flexibility is available for developing and enhancing the business computing OO framework.

The Interface class hierarchy is an aggregation of three major subclasses: User-Graphical User Interface, Remote Connectivity Interface, and Interoperability Interface (see Figure 3). These subclasses in turn contain other subclasses linking specific groups of major objects; for example, the Remote Connectivity subclass is an aggregation of the Application-Application Interface and Application-Data Interface subclasses. The Application-Application Interface may contain certain concrete interfaces linking a particular set of applications. The concrete interface subclasses consist of core attributes and methods used to carry out the interface management and linking functions between class objects. Certain specific interface subclasses may also include additional attributes and methods, depending on business requirements.

Business objects association. Figure 4 shows the conceptual relationships between a business process and the major classes, as well as the Interface classes linking the major classes. The 1+ in the figure represents the cardinality of the relationship in each set of object classes. For example, one or more instances of a User class may be associated with an instance of a Business Process class. Similarly, one or more Business Process classes may be using a Data class object. Recall that the User, Application System, and Data classes are linked by using the Interface classes to aid design flexibility. For example, an instance of an Application System class may access an instance of a Data class using an Application-Data Interface class.

The association between each Business Process class and the corresponding User, Application System, and Data classes are mapped in a Class Association Map (see sample in Table 3), which is part of our framework. The result is a mapping database to structure the design, development, and modification of the proper interface classes for the access, authorization, and logic of the various framework objects. The initial values of certain key attributes may also be listed in the Class Association Map; developers can then use them to define and modify the interface classes needed to create the linkages throughout the enterprise. For example, the business process of customer order processing in a customer-order-processing application may involve an order-processing system, a product-inventory database, a product-price database, a customer-information database, and three levels of user access: a clerk with read and write privileges over certain data (AccessLevel=1); a manager with read, write, and modify privileges over all data in that area (AccessLevel=2); and an administrator with supervisory rights (AccessLevel=3).

Other attribute values for Location and Department are also defined in the Class Association Map. The developer designs the User-Application and Application-Data interfaces according to the Class Association Map. These interfaces aid in an elegant and efficient procedure for creating objects and linkages between various classes, while facilitating reuse of objects created earlier without having to substantially change or recreate the classes themselves.

The result is an OO-business-process class hierarchy that supports an organization's informational requirements. This hierarchy is mapped onto an abstract IS infrastructure hierarchy of classes consisting of the three major ones—User, Application System, and Data. The class hierarchies of the individual computing infrastructure components are then developed; design templates create the classes. The associations and interactions are also developed, and an Interface class aids the integration and interoperability of the major framework elements.

Back to Top

Cost Estimation

A 1998 Computerworld survey of Fortune 1,000 companies found that 48% of responding companies planned to buy application systems based on their business requirements, while 36% planned to build their own business application systems [10]. Building and integrating these systems efficiently and cost-effectively is clearly of prime importance to business organizations. Our cost assessment model and total-cost-of-ownership evaluation template measure the cost of planning, developing, and maintaining an enterprise's OO business computing framework. It facilitates the estimation of the life-cycle costs of a planned computing environment. The model identifies certain key cost elements pertaining to the life-cycle phases of a system's planning, development/acquisition, implementation, and management (see Figure 5). While the cost components and their value may differ among organizations, the figure shows some typical cost properties of each phase of the framework life cycle.

A number of infrastructure-development methods, including incremental, waterfall, evolutionary, and rapid application development, may be used to estimate the costs for the OO computing framework. Depending on which approach is used, the costs of the various phases may overlap, as shown in the figure. Some of these methods, including prototyping, are especially amenable for building OO frameworks. We designed our model from the perspective of initial system development. Other situations, including system/environment scaling and upgrades and legacy integration, can also use the model by customizing the cost-estimation framework.

Planning. This stage consists of three main operations: requirements definition, systems analysis, and system design for the overall business computing framework [9]. A business process is decomposed in terms of the objects in the whole system; the elements of the computing framework are developed based on the system objects. For example, an inventory control system may require interactions among specific User, Application System, and Data classes. The objects and their allocations across different locations are also part of the planning process. The planning phase is generally coordinated by the development team using input from a select group of users. The major costs of this phase stem from the related human resources costs of its developers and users.

The planning costs are the overall costs incurred in the requirements definition and systems analysis phase of the framework elements. Direct costs include mainly those associated with system analysts' time and the active involvement of select users. The cost of analysts' and users' time can be estimated by averaging their average hourly wage rate over a one-year period (more if available). (Table 4 shows an estimation procedure of the cost components for this stage.)

Development. The major operations of this stage are the programming, testing, review, pilot implementation, and documentation of the framework elements. The costs for each of them is usually distributed among the developer and user teams, with some components being more developer heavy than others, as in Table 4. Depending on the type of time-accounting and employee-log used by a particular organization, development costs can be calculated per framework element, including the Application System object, Data object, and Interface object.

Direct development costs include those related to developer time, testing time, and the hardware, software, infrastructure, and development environment. The costs for hardware, communications and networking, off-the-shelf systems; other things may either be prorated for this phase or accounted for as a cost over the system's lifetime. Programming and testing costs are relatively developer heavy and may include some hardware and software costs.

The cost of review and pilot implementation includes developer and user time and depends on the rigor of the review and pilot study. The pilot costs also include user time during the testing and user-acceptance phases. A thorough review and pilot phase may uncover many system pitfalls early and help eliminate them more cost effectively. A thorough risk analysis should also be carried out during the planning and development stages to estimate the framework-development costs related to scope creep and time overruns, as well as the business-related risks of introducing new systems.

The cost of documentation during the development phase is one of the most important though often overlooked costs. Managed properly, it can save an organization substantially over the lifetime of the framework.

Development costs can be estimated through expert judgment methods (such as the Delphi Method, used to arrive at a position through repeated interrogations or questionnaires of group members), theoretical methods (such as Halstead's Software Science, used to estimate programming effort, measure program quality, and predict maintenance effort, as well as the rate of programming bugs), analogy with past projects, function point analysis, and critical path analysis [5]. When using these methods, it is necessary to estimate the associated software metrics, including the number of entities, attributes, and relationships. The result is that the costs of commercial off-the-shelf systems and other contracted-out systems can be calculated directly.

Implementation. The implementation phase of the framework consists mainly of installation, integration, infrastructure, and training. The cost of implementation covers installation of framework elements, integration with existing and new infrastructure and systems, new infrastructure, and user training, as in Table 4.

The cost of installation includes administrative and network coordination costs incurred during installation of the framework's objects throughout the enterprise. The cost of integration involves additions, deletions, and changes to existing computing architectures, interfaces, and network modifications. The cost of infrastructure can include additional hardware and software and network coordination for implementing the infrastructure changes.

User training—one of the most important and significant costs at this stage of the framework life cycle—includes the costs associated with instructor-led training, development of training materials, computer-based training, self study, end-user training, and even informal training among users. The 1998 Computerworld survey estimated that the time spent by users in end-user and informal training is equal to the time spent in instructor-led training, and that the time spent in self study is twice that of instructor-led training [6]. New systems entail significant costs for training; 84% of all formal training takes place in instructor-led classrooms [4]. Depending on an organization's internal accounting procedures, the implementation cost per framework element may be calculated through the cost-estimation template, which describes the major cost elements in the implementation phase.

Management. While these components of framework development represent mainly one-time costs, the management-phase costs of the framework recur throughout a system's life cycle. The management phase consists mainly of maintaining, supporting, improving, and enhancing an organization's user productivity while using the framework elements, as in Table 4. The management costs can be evaluated monthly, quarterly, or yearly, depending on which accounting procedures an organization follows; however, they must be applied consistently across all components, which may be developed in-house, acquired, or leased. Maintenance costs include routine additions and changes to the existing infrastructure, software maintenance and licensing, and backup and disaster recovery.

Depending on organizational structure, these costs can be estimated through the cost-assessment model as a percentage of a support person's time spent on each element. Likewise, the costs of the support functions involved in managing the business computing framework include those for the help desk, troubleshooting, developer support, data security, how to grant proper authorizations to users, and routine network coordination and administration. Most of them are calculated as a percentage of the support personnel and network coordinator time spent on each function. Improvement costs cover hardware, software, and other infrastructure related to the upkeep and integration of the various elements, as well as the friendliness of the user interfaces and incremental changes to the framework elements, fine tuning and aligning them in light of changing business requirements.

The amount of lost user productivity can be estimated by calculating the data-recovery costs associated with user data loss, as well as downtime costs, which can be estimated using server downtime and support personnel logs. Some estimates have been suggested for calculating the productivity loss [6].

The result is a cost-assessment framework that estimates the planning, development, implementation, and management costs of an enterprise computing framework. While the first three elements—planning, development, and implementation—represent mainly one-time costs during the life cycle of the framework elements, the cost of management recurs throughout the system's lifetime.

Back to Top

Conclusion

The generic OO framework we described here helps corporate IT management and enterprise OO system developers design and develop an enterprise's complex business computing systems. A related cost assessment model helps evaluate the framework's cost effect on the organization. The framework models business processes as hierarchies of classes, and the elemental classes of the business-process hierarchy are mapped onto an abstract IS-infrastructure class hierarchy. The abstract elements are further modeled as hierarchical classes; an Interface class helps integrate the elements.

The related cost-assessment framework calculates the costs of planning, developing, implementing, and maintaining the component elements of a distributed computing environment throughout its life cycle.

Combined, these frameworks yield a set of templates for analysis, design, development, and cost estimation, all customizable by the organization using them.

Back to Top

Back to Top

Back to Top

Back to Top

Back to top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2000 ACM, Inc.

---

No entries found