Systems, Process & Data Modeling in Researching

Advantages of the case model method

A case study may be defined as a method that “examines a phenomenon in its natural setting, employing multiple methods of data collection to gather information from one or a few entities (people, groups, or organizations).” (Benbasat, Goldstein, & Mead, 1987, p. 370) Case model method was developed to do away with the kind of information provided through a multivariate quantitative analysis (Van Maanen, 1982).

The primary advantage of a case model method is overcoming the complexities of multivariate quantitative research method, conducting the research is a problem, the need to employ a large sample size for these researches and the difficulty of interpreting the quantitative methods used (Benbasat, Goldstein, & Mead, 1987). Further, a case model method supports an idiographic research strategy for information system (IS) study which is a suggested method for IS research (Franz & Robey, 1984 ). But selection of a strategy for research depends on the situation of the research (Benbasat I. , 1984).

Case research is particularly appropriate for certain types of problems: those in which research and theory are at a formative stage (Roethlisberger, 1977), and “sticky, practice based problems” where both the actor and the context of the action are important (Bonoma, 1983). Benbasat et al. (1987) believe that the case research method is well-suited to capturing the knowledge of practitioners and developing theories from it. Further due to a shift of the focus of IS studies from technological to managerial aspects hence it has become important to understand the interplay between the innovation (i.e. the IS) and the context. For instance, airline reservation systems were very innovative technical achievements in the early

1960s. However, they became a key competitive factor in the changing airline industry within the last few years. In order to understand this phenomenon, one must examine the structure of the industry, the role of deregulation, and the federal laws governing the industry (Benbasat, Goldstein, & Mead, 1987).

According to Benbasat et al. (1987), there are three reasons why case research methods are advantageous to IS research. First, the researcher can learn about the IS from the natural setting, and generate theories from practice. Second, a case research method is appropriate to answer the “how” and “why” questions. This allows understanding of the nature and complexity of the processes taking place.

As Benbasat et al. states: “Questions such as, “How does a manager effectively introduce new information technologies?” are critical ones for researchers to pursue.” (1987, p. 370)Third, a case research method is appropriate to be used in studying an area where few prior researches had been conducted. This is applicable in the IS field due to the rapid pace of change in IS technology innovations (Benbasat, Goldstein, & Mead, 1987).

Benbasat et al. (1987)studied the case study methods of different researches and evaluated their strengths and weaknesses then they rated the whole samples of the cases. The first identified disadvantage is the lack of clearly defined objectives of research. Most of the case studies are exploratory in nature and failed to point out the topic of research clearly (Benbasat, Goldstein, & Mead, 1987). Another problem that can be noticed incase research methods was difficulty to infer whether the authors’ goal was a literal or theoretical replication, or whether the cases were chosen for exploratory or illustrative reasons.

Further, a case approach does not have a systematic research plan. A case study approach makes the study appear to be a standalone research in the field without any connection to other researches as in this method no review of the existing literature is done. This approach does not describe the method of data collection in detail which does not provide any revealing information. Further this method has mostly been used for exploration and hypothesis building and thus does not provide a complete model for IS research. Another problem of undertaking a case study based research are “direct observation in the actual contemporary situation cost, time, access hurdles, the need for multiple methods, tools, and entities for triangulation; the lack of controls, and the complications of context and temporal dynamics.” (Meredith, 1998, p. 444)

Apart from another critical disadvantage of the case method is the lack of familiarity of its procedures and rigor by other academicians (Meredith, 1998). Many academicians like Aldag and Stearns (1988) has questioned qualitative research in general as being commonly perceived as exhibiting a tendency for construct error, poor validation, and questionable generalizability. Case research method was also considered to be least systematic of all other research methodologies applied for IS research (Stone, 1978). Benbasat et al. (1987) believes that a case research lacks the clear description regarding the fitment of the topic into building the knowledge base. Lee (1989) indicated the methodological problems involved in the study of a single case. The problems identified by Lee are as follows:

1. The first problem was that of making controlled observation. Lee observes that more variables points are deduced from a single case study than data points. Further, it has the same problems as a laboratory research.
2. Second, problem is how a controlled deduction should be made. This is easier to accomplish in case of quantitative methods, but difficult in case of a qualitative research process.
3. Another problem with IS case research is the problem of allowing replicability as replication of the same real-time set-up of one case research is a very difficult task.
4. The fourth problem is allowing generalizability. Generalization of a research is a unique characteristic of scientific research methodologies which helps in their applicability in various studies. But the very nature of a single case study of non-replicability makes generalization of the research not possible.

Recent study of the case research methodologies show that cases were selected on the basis of availability of the cases (Dubé & Paré, 2003). It has been found that researchers mostly do not explain the method of data collection and how data collection methods contributed to the research findings. The recent study though states that there has been a marked improved in multiple data collection method and mentioning the case selection criteria (Dubé & Paré, 2003).

Descriptive case studies lag far behind explanatory and exploratory studies with respect to several attributes. As a clear indication of this, explanatory and exploratory case studies were much more explicit in regard to the data collection and data analysis processes. Explanatory and exploratory case studies also made much greater use of multiple cases, relied more heavily on multiple data collection methods as well as on a combination of qualitative and quantitative data, and searched more for cross-case patterns. This is especially unfortunate because descriptive case studies appear to be the dominant type of case study performed (Dubé & Paré, 2003).

Ethics in research deals with the researcher’s responsibilities of the research approach and outcomes (Hirschheim, Iivari, & Klein, 1996). It falls upon the researcher to explicitly divulge the research aim and outcome in order to provide a clear cut description of the findings. It is believed that the ethics of research should be portrayed as explicitly as possible (Mattessich, 1978). The first issue that arises as an ethical question in IS research is goal setting.

While doing a case study based research it is often seen that the goal of the research follows action which is not ethically acceptable in research as it indicates formulation and reformulation of the goals (ends) on the basis of the research findings (Hirschheim, Iivari, & Klein, 1996). Further a research into IS may serve the interest of a particular dominant group. A case study research is often smeared with this bias as the research may serve interest of that dominant group. a researcher should provide unaltered findings and the research should not be manipulated to provide a finding to suit interests of a special group.

The case study research method’s ethical view of research science is highly interpretive because of its major interest is in the actual consequences of computing, including symbolic, ceremonial, and ritual use. The case researches are mostly involved in the implementation process and avoid interpretation of the IS design part with a means-end orientation (Kling, 1980). Regarding the values of IS research, the approach takes no clear position (Hirschheim, Iivari, & Klein, 1996).

Use-case modeling

The development of Unified Modeling Language (UML) in the information technology industry underwent in the 1990s. Unification was lead by Rational Software Corporation and Three Amigos, Grady Booch, James Rumbaugh, and Ivar Jacobson. Use case modeling was first developed by Jacobson et al. (Jacobson, Christerson, Jonsson, & Overgaard, 1992) as a requirement modeling technique. Use case modeling is a functional decomposition technique that provides a semi formal framework for structuring requirements.

The application of use case diagrams first demands an understanding of the types of elements used in use case diagrams. Actor classes are used to model and represent roles for “users” of a system, including human users and other systems.

• Actors are denoted as stick person icons. They have the following characteristics:
• Actors are external to a system.
• Actors interact with the system. Actors may use the functionality provide by the system, including application functionality and maintenance functionality. Actors may provide functionality to the system.
• Actors may receive information provided by the system. Actors may provide information to the system.
• Actor classes have actors’ instances or objects that represent specific actors.

Figure 1 shows a project management system with a project manager actor and a project database actor. The project manager is a user who is responsible for ensuring the success of project and uses the system to manage projects. The project database is a system that is responsible for housing project management data.

Use cases are used to model and represent units of functionality or services provided by a system (or parts of a system: subsystems or classes) to users. Use cases are denoted as ellipses or ovals. They may be enclosed by a system boundary or rectangle labeled with the name of the containing system. They have the following characteristics:

• Use cases are interactions or dialogs between a system and actors, including the messages exchanged and the actions performed by the system. Use cases may include variants of these sequences, including alternative and exception sequences.
• Use cases are initiated by actors and may involve the participation of numerous other actors. Use cases should provide value to at least one of the participating actors.
• Use cases may have extension points that define specific points within an interaction at which other use cases may be inserted.
• Use case classes have use case instances or objects called scenarios that represent specific interactions. Scenarios represent a single sequence of messages and actions.

Figure 1 shows a project management system which provides the functionality to manage projects in which the project manager and project database participate.

Association relationships between actor classes and use case classes are used to indicate that the actor classes participates and communicates with the system containing the use case classes. Association relationships are denoted as solid lines or paths. Arrowheads may be used to indicate who initiates communication in the interaction. If an arrowhead points to a use case, the actor at the other end of the association initiates the interaction with the system. If the arrowhead points to an actor, the system initiates the interaction with the actor at the other end of the association.

Figure 1 shows a project management system that provides functionality to manage projects. A project manager initiates this functionality and the system initiates the communication with the project database in providing this functionality. Includes relationships from base use case classes to inclusion use case classes are used to indicate that the base use case classes will contain the inclusion use case classes; that is, the base use case will contain the inclusion use case.

A base use case defines the location at which the inclusion use case is included. Includes relationships are denoted as dashed lines or paths with an open arrow−head pointing at the inclusion use case and are labeled with the <> keyword (stereotype). The insertion of the inclusion use case involves the execution of the base use case up to the inclusion point, inserting and executing the inclusion use case, and then continuing with the execution of the base use case.

Figure 2 shows that a project manager may add projects and remove projects using the project management system. When removing projects, the functionality of finding a project is included into removing a project.

Extends relationships from extension use case classes to base use case classes are used to indicate that the base use case classes may be augmented by the extension use case classes; that is, the inclusion use case will augment the base use case if an extension condition is satisfied. A base use case defines the extension point. An extension use case defines the extension condition that must be satisfied in order to insert the extension use case into the base use case.

The insertion of the extension use case involves the execution of the base use case up to the extension point, testing the extension condition and inserting and executing the extension use case if the condition is satisfied, and then continuing with the execution of the base use case. Extends relationships are denoted as dashed lines or paths with an open arrow−head pointing at the extension use case and are labeled with the extension condition in square brackets, the <> keyword (stereotype), and the extension point name in parentheses. Extension points are identified in a compartment labeled “Extension Points” in the base use case.

Figure 3 show that a project manager may update projects using the project management system. When updating projects, a project manager may manage tasks if the project manager selects the task option, and a project manger may manage resource if the project manager selects the resource option.

Generalization relationships from specialization use case classes to generalized use case classes are used to indicate the specialization use case classes are consistent with the generalized use case classes and may add additional information. A specialization use case may be used in place of a generalized use case and may use any portions of the interaction of the generalized use case. Generalization relationships are denoted as solid lines or paths with a hollow arrow−head pointing at the generalized use case.

Figure 4 shows that a project manager may publish a project schedule by sending e−mail to project team members using an e−mail system or by generating a web−site on a web−site host. In either case, there will be common functionality used from the generalized use case, for example, inputting project name, extracting the relevant project information from the project database, etc.

Generalization relationships from specialization actor classes to generalized actor classes are used to indicate the specialization actor classes are consistent with the generalized actor classes and may add additional information. A specialization actor may be used in place of a generalized actor and receives the characteristics of the generalized actor. Generalization relationships between actors are denoted similarly to generalization relationships between use cases.

Figure 4 shows that there are two types project managers, full−time and part−time, and that there are two types of project database, relational database management systems (R−DBMS) and object oriented database management systems (OO−DBMS). Any type of project manager may publish a project schedule using any type of project database.

Process modeling

The concept of Business Process Modeling (BPM) evolved from the generalization of different approaches to Business Process Reengineering (BPR) (Davenport, 1993; Kettinger, Guha, & Teng, 1995). IT investments of any sort must be viewed as part of the business processes in their organizations. The notion of what constitutes IT must be expanded to include not only the chips, wires, and software, but also the activities and interactions that generate the costs and valuethat results from using the IT (i.e., the enterprise architecture).

Failing to map and understand the enterprise invites a badly flawed understanding of how the IT investment will work, and can be a short cut to failure. For example, the U.S. Department of Education recently invested millions of dollars in a Web site for college students to apply for financial aid. The site generated very little use and was closed down. It failed because it ignored the important role of college financial aid officers in the overall process of students seeking and receiving aid. The designers did not understand or ignored the overall business process of financial aid administration.

Business process analysis tools and methods range from simple flow and GANTT charts to sophisticated formal and mathematical modeling. Simple flow charts are sufficient to identify the basic elements of most business processes and some of the more obvious dependencies. How far business process modeling needs to go beyond simple diagrams depends on the questions to be answered and the resources available for the work. The basic components of a business process are activities, flows, controls, and dependencies.

Analyzing the business process therefore means identifying the various kinds of activities, what kinds of flows they generate and support, and how the activities and flows are controlled and linked to produce some particular collection of goods or services. Flows can consist of information, persons, resources, control inputs, and work products moving from one activity to another. The analysis consists of gathering information about the activities and flows in as much detail as necessary.

Depending on the kinds of modeling to be used, this information can include descriptions of activities and flows in strictly qualitative terms or detailed measurements of resources used, flow metrics, and outcome measures. Both the costs and returns of the investment are tied to how the new technology fits with and how it BPM is essential for BPR lifecycle (Lin, Yang, & Pai, 2002). BPM method possesses the analysis capability in facilitating process evaluation and alternative selection. To serve these purposes, computer simulation is applicable due to the progress of information technology. A business process consists of five elements as developed by Davenport (1993) :

1. A business process has its customers;
2. A business process is composed of activities;
3. These activities are aimed at creating value for customers;
4. Activities are operated by actors which may be humans or machines; and
5. A business process often involves several organizational units which are responsible for a whole process.

A categorization of process modeling was done by Kueng et al. (1996) :

1. Activity-oriented approaches tend to define a business process as a specific ordering of activities (sometimes referred to as tasks). They generally offer good support in refining process models. However, this mechanistic view may fail to represent the true complexity of work and, in turn, fail to implement new business processes.
2. Object-oriented approaches are associated with object orientation, such as encapsulation, inheritance, and specialization. The principles of object orientation are applicable to business process modeling. However, practitioners, such as process owners and team members, tend to describe their work by activities rather than by objects.
3. Role-oriented approaches suggest that a role be involved in a set of activities, and carry out particular responsibilities (Ould, 1995). A group of primitive activities can be assigned to a particular role (i.e. actor or agent). However, they are not suitable to express an intricate sequencing logic.
4. Speech-act oriented approaches, based on speech act theory under language/action perspective, view the communication process as four phased loop: proposal, agreement, performance, and satisfaction (Medina-Mora, Winograd, Flores, & Flores, 1992). Although business cases can be viewed as a communication between customers and performers, this modeling approach does not provide much help in analyzing existing processes or creating new processes.

Once a categorization of business processes are done, the essential concepts required to define business processes are considered. Curtis et al. (1992) propose four common perspectives in modeling business process.

In the functional perspective, a model represents what process elements are performed. These process elements may consist of objects, data, artifacts, or products. In the behavioral perspective, a model represents when process elements are allocated (e.g. sequencing), and how related actions are performed. In the organizational perspective, a model represents where and by whom in the organization process elements are performed. In the informational perspective, a model represents the informational entities produced by a process, such as data, documents, etc. It includes the structure of information entities and their relationships.

There are different methods which may aid the understanding of process modeling. The basic components of a business process are activities, flows, controls, and dependencies. Analyzing the business process therefore means identifying the various kinds of activities, what kinds of flows they generate and support, and how the activities and flows are controlled and linked to produce some particular collection of goods or services.

Flows can consist of information, persons, resources, control inputs, and work products moving from one activity to another. The analysis consists of gathering information about the activities and flows in as much detail as necessary. Depending on the kinds of modeling to be used, this information can include descriptions of activities and flows in strictly qualitative terms or detailed measurements of resources used, flow metrics, and outcome measures.

Business process models make the implicit assumptions and mental models of individual managers and stakeholders more explicit and open for discussion. They also:

• Inhibit premature jumping to a solution because of the way they structure thinking about a problem;
• Create an externalized definition of the problem that can serve as a focus of discussion and can help to align thinking about what are root causes of observed problems;
• Force managers and analysts to come to grips with the precise logic or causal forces that are causing a problem;
• Require attention to decide which key variables to measure;
• Allow analysts and managers to communicate their reasoning effectively and efficiently to external audiences;
• Can provide a simulation of how the full system will operate within a full context of organizational and human factors;
• Push managers to see the implications of a limited prototype when it is expanded to full scale operations, requiring careful attention to technical, organizational, and policy issues; and
• Can include financial elements that allow explicit exploration of costs and benefits of proposed solutions.

Sensitivity analyses of models provide answers to “what if” questions about various types of system functionalities and possible organizational and human effects. This helps planners anticipate issues and problems before they are encountered in a real world system implementation.

The limitations of process modeling are prevalent among project management techniques. The primary drawback is that this modeling increases the cost of analysis to a great extent. These models typically require more detailed and extensive information, particularly performance and outcome measures, than simpler descriptive methods. In addition, the construction and use of these modeling methods requires considerable time and expertise. Organizations that do not have staff prepared to do the modeling work themselves would have to invest in either extensive training or employing consultants. It is important to review carefully whether the complexity of the project justifies the investment in formal modeling before taking that course of action.

Works Cited

Aldag, R., & Stearns, T. (1988). Issues in research methodology. Journal of Management vol. 14 no. 2 , 253–273.

Benbasat, I. (1984). An Analysis of Research Methodologies. In F. W. (ed.), The Information Systems Research Challenge (pp. 47-85). Boston, Massachusetts: Harvard Business School Press.

Benbasat, I., Goldstein, D. K., & Mead, M. (1987). The Case Research Strategy in Studies of Information Systems. MIS Quarterly (September) , 369-387.

Bonoma, T. (1983). A Case Study in Case Research:Marketing Implementation. Boston, Massachusetts: Working Paper 9-585-142, Harvard University Graduate School of Business Administration.

Curtis, B., Kellner, M., & Over, J. (1992). Process modeling. Communication of the ACM, Vol. 35 no.9 , 75-90.

Davenport, T. (1993). Process Innovation: ReengineeringWork Through Information Technology. Boston,MA: Harvard Business School Press.

Dubé, L., & Paré, G. (2003). RIGOR IN INFORMATION SYSTEMS POSITIVIST CASE RESEARCH: CURRENT PRACTICES,TRENDS, AND RECOMMENDATIONS. MIS Quarterly Vol. 27 No. 4 , 597-635.

Franz, C., & Robey, D. (1984 ). An Investigation of User-Led System Design: Rational and Political Perspectives. Communications of the ACM, Volume 27, Number 12 , 1202-1217.

Hirschheim, R., Iivari, J., & Klein, H. K. (1996). A Paradigmatic Analysis Contrasting Information Systems Development Approaches and Methodologies. Information Systems Research Vol. 9, No. 2 , 164-194.

Jacobson, I., Christerson, M., Jonsson, P., & Overgaard, G. (1992). Object oriented software engineering: A Use Case Driven Approach. US: Addison-Wesley.

Kettinger, W., Guha, S., & Teng, J. (1995). The process reengineering life cycle methodology: a case study. In V. a. Grover, Business Process Change: Reengineering Concepts,Methods and Technologies (pp. 211-44). London: Idea Group Publishing.

Kling, R. (1980). The Social Analyses of Computing. ACM Computing Surveys vol. 12 no. 1 , 61–110.

Kueng, P., Kawalek, P., & Bichler, P. (1996). How to compose an object-oriented business process model?. In S. e. Brinkkemper, Method Engineering. Atlanta, GA.: Proceedings of the IFIP WG8.1/WG8.2 Working Conference.

Lee, A. S. (1989). A Scientific Methodology for MIS Case Studies. MIS Quarterly vol. 13 no. 1 , 33-52.

Lin, F.-R., Yang, M.-C., & Pai, Y.-H. (2002). A generic structure for business process modeling. Business Process Management Journal, Vol. 8 No. 1 , 19-41.

Mattessich, R. (1978). Instrumental Reasoning and Systems Methodology: An Epistemology of the Applied and Social Sciences. Dordrecht, Holland: D. Reidel Publishing Company.

Medina-Mora, R., Winograd, T., Flores, R., & Flores, F. (1992). The action workflow approach to workflow management technology. Proceedings of the Conference on Computer-Supported Cooperative Work (pp. 281-8). Toronto: CSCW’92.

Meredith, J. (1998). Building operations management theory through case and field research. Journal of Operations Management 16 , 441–454.

Ould, M. (1995). Business Processes: Modeling and Analysis for Re-engineering and Improvement. Chichester and New York, NY.: Wiley.

Roethlisberger, F. (1977). The Elusive Phenomena. Boston, Massachusetts: Harvard Business School Division of Research.

Stone, E. (1978). Research Methods in Organizational Behavior. Santa Monica, CA: Scott, Foresman & Co.

Van Maanen, J. (1982). Introduction. In J. V. Maanen, Varieties of Quafitative Research (pp. 11-29). Beverly Hills, California: Sage Publications.