Strategies to Deal with Complexity in Information Systems Development

16 downloads 0 Views 91KB Size Report
Information Systems Development (ISD) is an organizational ... organization's mission, main activities, structure, etc.;. 2) Study ..... Analysis and Design Method.
Strategies to Deal with Complexity in Information Systems Development João A. CARVALHO Information Systems Department , School of Engineering and Algoritmi R&D Centre , University of Minho, 4800-058 Guimarães, Portugal

ABSTRACT Information Systems Development (ISD) is an organizational activity that attempts to improve an organization’s information system through the adoption of information technology (IT) products. The complexity of organizations, of their information systems, and of the IT products is dealt with by the use of models of any of these entities. These models help to reduce that complexity, to share and validate understandings among the participants in the ISD process, and to guide developers throughout the implementation process. Several mechanisms and strategies to deal with complexity are implicit in the models built during ISD. They include basic intellectual mechanisms such as abstraction but also strategies that enable to reduce the quantity or diversity of elements and their interrelations that bring out complexity. These strategies are used in the two main steps of modeling: conceptualization and representation. The strategies mentioned in this paper include: partitioning and systems thinking for the conceptualization step; levels of detail, projection and partition for the representation step. The paper attempts to illustrate the differences among the strategies and how they are used in ISD. It aims to contribute to a better understanding of the modeling process (specially in information systems modeling) that can lead to a better use of these strategies and to avoid confusion and misunderstanding in their application.

Keywords: information systems development, complexity, modeling, systems thinking, partition, projection

4)

Obtain the IT products – develop the IT product, or subcontract their development, or acquire IT products as COTS1 products;

5)

Implementation of the organization’s IS – training of people to deal with the new IS; preparation of new forms; conversion of information from old to new formats; operation of new IT products; etc..

During the ISD process three entities are object of interest by IS developers: the organization; the organization’s information systems; the IT products. All these three entities are complex. Organizations and their IS involve people and artifacts carrying out purposeful work. IT products combine several IT components in order to be able of performing information handling tasks that are part of the organizational work. In order to deal with this complexity, IS developers build and represent models of organizations, of their IS and of the IT products to share and validate understandings among the participants in the ISD process and to guide developers throughout the implementation process. This paper presents and discusses several strategies that are normally used during the ISD process modeling process in order to deal with complexity.

2. MODELING In this paper there is an important distinction between model and model representation. Models are conceptualizations of something, someone is paying attention to. They are ideas that exist in the minds of people. Model representations are depictions of those ideas that are used to share them with other people. This distinction is illustrated in figure 1.

1. INTRODUCTION Information Systems Development (ISD) is an intervention activity whose purpose is to improve an organizational situation through the adoption of information technology (IT) products [1], [2]. The intervention is made in the organization at the level of its information handling activities. The result of the intervention is a new organizational situation where one or more IT products have been put at work and several changes on the way organizational activities were carried out. The ISD process can be described as including the following activities [2]: 1)

Study of the organizational context – understand the organization’s mission, main activities, structure, etc.;

2)

Study of the organization’s information system (IS) – understand the organization’s information handling activities and the information that is handled;

3)

Re-design of the organization’s IS – redefine the organization’s information handling activities; define the requirements for the IT products;

A

Mental model

REPRESENTATION

CONCEPTUALIZATION World of models “Real” world Modeler

A Entity that is object of attention

A Representation of model

Figure 1 – Entities, models and the representation of models

1 Commercial Of The Shelf.

Building models – modeling - can be described as encompassing two steps: conceptualization and representation. •



Conceptualization corresponds to the intellectual endeavor related to understanding or designing an entity (e.g., an organization, its IS, IT products) and creating a mental/intellectual model of that entity. Conceptualization can be made as result of some inquiry upon an existing entity or it can correspond to the design of some entity that doesn’t exist yet. Representation corresponds to the activity of depicting the mental/intellectual model that resulted from the conceptualization step, using some language(s).

Modeling is a complexity handling mechanism. Models are simplified views of some entity (e.g., objects, events) that help reasoning about the entity and to interfere with it. A model is the result of someone’s thoughts about something. Model representation is unavoidable whenever more than one person are involved or when someone wants to share his/her thoughts with other people. The complexity of something (either the entity that is object of attention, its model or even the corresponding representation) is related to the quantity and diversity of elements and the interrelations among those elements that compose the thing. To deal with the complexity can be described as a problem of how to reduce the quantity or diversity (or both) of elements and interrelations. Abstraction First of all, modeling implies the application of abstraction. Abstraction is a mechanism of intellectual simplification that ignores some details of an entity of interest that are considered irrelevant for some purpose. It enables that attention is focused on what is believed to be the essential aspects of the entity therefore leading to a simplified view of the entity – a model. Abstraction can also lead to the formation of general concepts (classes or categories) that correspond to several objects in the real world [3], [4]. Through the use of classifications it is possible to deal with classes of entities instead of individual entities. Through abstraction both quantity and diversity are tackled. Quantity is reduced because the focus is put on groups of entities instead of individuals. Diversity is reduced because things with several different characteristics are classified under the same category. Associated to models and modelling two other important concepts should be mentioned: meta-models [5], [6] and ontologies. Meta models are the result of applying modeling to a model. The result is a schema of modeling concepts. This schema helps the modeler to be aware of what to look for when carrying out the inquiry associated to the conceptualization of the model of some entity of interest. Meta-models act as filters that enable the modeler to view the world according to some schema of general concepts. When representing a model, the meta model constitutes the key – the legend or caption – that enables the interpretation of the model. Ontologies are the result of a prior abstraction endeavour that is reused in a new but similar situation. A previously built

2 model is understood as sufficient general to be applied to other situations which are considered to be similar in respect to some criteria. Normally ontologies apply to a class of business such as an ontology for finance organisations, for insurance organisations or to the automobile industry. Language It is not easy, or even, possible to separate thinking and language (representation technique). The way someone think about something is surely influenced by the way that person represents (externally to his/her mind) the ideas he attempts to reason about. But language constitutes a particularly important aspect when tackling complexity during the representation step. Different languages have different expressiveness degrees and are different in what concerns its readability. Formal (mathematical) languages are normally more difficult to read although they might have very good expressiveness. Diagrammatic languages are normally easier to read – one image is worth one thousand words. However, attention should be paid in order to increase the rigor of diagrammatic languages and to avoid ambiguity. For instance, Martin [7] suggest a standardization of symbols to be used across several diagrammatic languages. Taking as illustration an example from the ISD area, a model of the structure of the information of an IS can be represented with languages such as NIAM [8], E-R (entity-relationship diagrams) [9], [10] [11] or OO (object-oriented) class diagrams [4], [12] [13]. These three different languages offer very different expressiveness degrees and readability [14]. Moreover, different languages will deal differently with quantity and diversity issues. So, depending on whom a representation is addressed to, the use of alternative different languages should be considered. Entities, models and model representations Besides the basic aspects mentioned above (abstraction, meta models, ontologies and languages), several strategies for complexity reducing can be used, addressing both conceptualization or representation. For each of these steps it is possible to identify different strategies to deal with the complexity. Figure 2 shows the elements that will be used to illustrate how the different strategies considered in this paper work to deal with the complexity of an entity (during conceptualization) or of its model (during representation). Model

Entity

Representation of model

Figure 2 – an entity, the corresponding model (mental/intellectual) and the representation of the model

3 3 COMPLEXITY REDUCING STRATEGIES USED IN THE CONCEPTUALIZATION PHASE

The same reasoning can then be applied to each of the subsystems leading to even lower level of detail models.

During the conceptualization phase, three main strategies can be applied: partition, systems thinking, and filtering.

When conceptualizing something as a system, five aspects should be considered [15], [16]: (i) purpose – the justification for viewing the entity as a system; (ii) the environment – the things that do not belong to the systems but which the system interacts with; (iii) activities – what the system does; (iv) the handled objects – the things that are manipulated by the activities; (v) the organs – whatever carries out the activities. Each of these aspects and combinations of some of these aspects are then object of attention. These aspects can be viewed as a systems meta-model as they correspond to general concepts for describing some entity as a system.

Partition Partition is a very simple strategy to deal with complexity – it takes the entity that is being studied and breaks it in pieces (divide to conquer). So, instead of one big and complex entity, there will be several smaller and simpler entities. This strategy addresses the quantity of elements to be dealt with. Figure 3 illustrates the application of the partition strategy. Entity

Model

It should be noted that these five aspects can also be considered in some part of an entity that resulted of the application of a partition strategy. However, their use does not guarantee that taking into account emergent properties has been watched over. This is what often happens when carrying out what is normally called systems analysis. Filtering

Figure 3 – Use of partition; the entity is broken in pieces; for each piece a model is created

In an organization, someone could address just one part of it as, for instance, the financial division or the marketing department leaving the rest of organization out of the study.

Filtering corresponds to the direct application of abstraction. It addresses the whole organization but it focus on some of its aspects leaving others out of the study. For instance, someone wants to address just the relationships among people. Or to study only the roles played by machines. Or the flow of documents. Figure 4 attempts to illustrate filtering. Entity

Systems thinking Partition can lead to a major problem: the entity that is being studied might exhibit properties that are apparent in the whole but do not exist in any of the considered parts – emergent properties. By partitioning the entity in several parts it is no more possible to explain those properties. Systems thinking can help to overcome this problem as it leads to a model of the entity as a whole, taking into account its emerging properties. Only then, a decomposition reasoning should be applied leading to another model that considers that the system is composed by several subsystems whose combination grants the system its emerging properties. Figure 5 attempts to illustrate this strategy.

Model a

Entity

Model

Figure 4 – Filtering

The modeler doing filtering can be described as using some special eyeglasses that filter what he/she is looking at, enabling him/her to view only parts of it, according to some pre-defined criteria. Therefore the result of filtering is not the whole organization but part of it. Information systems are often described as encompassing the organizational activities that handle information (collect, store, process, transmit, etc.). Such description suggests the use of a filtering strategy rather than a systems thinking strategy, although the term system is used. So, as explained in the previous sub-section, only a system meta-model is being used.

4 COMPLEXITY REDUCING STRATEGIES USED IN THE REPRESENTATION PHASE Model b

Figure 5 – Systems thinking leads to a model that depicts the entity’s properties (model a – the whole; model b – the whole has been subdivided in three sub-systems)

Although it is a simplified view of an entity, the model (the mental model) can also be complex. And the same happens with the model representation. So, caution should be taken when representing a model. This section addresses strategies

that can be used during the representation phase in order to reduce the complexity of a model or its representation. As it has been mentioned before, complexity reduction is achieved by reducing the quantity or the diversity of elements and interrelations that have to be dealt with.

4 justifies why most ISD methodologies suggest more than one language (e.g., structured approaches – already mentioned before - IDEF [21], [22], UML [12]). Each language is used to represent one projection of the model of the entity (very often an IT product) being addressed.

The strategies to deal with complexity during representation that will be considered include: levels of detail, projection, and partition.

Model

Representations of model:

Levels of detail

Projection 1)

Instead of presenting a model using one single and “complete” representation it is sometimes advised to start with a global, low detailed, view of the model, providing then several more detailed representations. With this strategy it is possible to reduce the quantity of details presented at each time and so, to reduce the complexity of a model. Figure 6 illustrates the use of levels of detail.

Projection 2)

Model Projection 3)

Representations of model:

Figure 7 – Use of projection; the model is represented using several projections

Level 1) M1

Partition

Level 2)

With the partition strategy the model is partitioned in several smaller models. Therefore, the quantity is reduced and so is the complexity. Figure 8 illustrates the strategy of model partitioning.

M2

Level 3) M3

M4

M5

Model

Figure 6 – Use of levels of detail; the representations are presented at increasing levels of detail allowing a gradual understanding of the model

The use of levels of detail can be achieved using either one single language (like, for example, the use of a set of data flow diagrams – DFD [17]), or using a combination of different languages (for instance, a primitive processes of a DFD can be exploded in a process description using an action diagram [7, 18]). The use of levels of detail in ISD has been popularized since the 1970 years with the publication of several ISD methodologies nowadays generally referred to as the structured approaches (e.g., SADT [19], structured analysis and design [17], [20], [10], [11], [18]).

Result of partitioning the model

Representations of model:

Projection Projection is a strategy that leads to the construction of a set of complementary representations instead of one single representation. Each representation accounts for a partial view or perspective of the model being represented. For each perspective some selection criteria is applied (see figure 7). Projection can be viewed as corresponding to filtering. However, while the former is used during representation the latter is used during conceptualization. The combination of the set of representations provides a global presentation of the model. Projection helps to deal with the diversity as each of the projections of a model focus on some (few) of its aspects. Projection is normally achieved through the use of several different languages. Projection

Figure 8 – Model partitioning

The term view if often used to refer to a part of a model. Model representation partition Partition can also be applied to the model representation. Instead of exhibiting the whole model representation, it is presented in several parts. Sometimes, the whole model is represented but some of its parts are highlighted (or some parts are semi-hidden) through the use of graphical tricks such as the use of colors, shading, etc.. Like this it is possible to emphasize parts of the model representation that are

considered to be more relevant for some purpose (see figure 9). Model representation

A partial view of the model

A partial view of the mode with the rest of the model semi-hidden

Figure 9 – Focusing and stressing parts of a model

5 DISCUSSION AND CONCLUSION Combinations of the strategies described in this paper are normally suggested by ISD methodologies and used by information systems developers. However, very often, information systems developers are not aware of the strategies they are using and fail to make the most of their use. Perhaps the first difficulty in distinguishing among strategies is rooted in the fact that many authors do not differentiate among the entity being modeled, its model and the model representation, the same way it has been done in this paper. It is common to see allusions only to the system and its model. System corresponds to the entity, the object of interest. Model to a representation of a simplified view of this entity. The practice of using these terms reflects that it is assumed that a systems approach is being used and that the objects of interest are therefore systems. The position taken in this article is that things are not systems but things can be viewed as systems (if they are complex enough to justify it). The common practice also reflects that there is an underlying assumption that there is one single possible way of viewing an object of interest. So, different modelers will produce the same model when confronted with the same object of interest. The stance in this paper is a subjective one: different modelers will view differently one same object and therefore it is necessary to consider the mental/intellectual model that results from a conceptualization. And because there are several possible languages to convey one idea, the model representation is considered as something separate from the model. The assumption that a systems approach is being used is particularly harmful as it makes IS developers to believe they are using a system thinking strategy when they are not. In fact they are combining a system meta-model with strategies that are not systems thinking strategies. Although systems concepts are used (a systems meta-model), they are not applied in a model that results from an attempt to view the object of interest as a whole. In ISD, in most cases, they are applied to a filtered scene of the object of interest. Systems analysis is perhaps the best example of this combination of a systems meta model with “non-systems thinking” strategies. The popularization of systems analysis among information

5 systems developers makes them believe that they are applying systems approaches even when applying partitioning strategies (this is very likely to happen when a systems analysis project is carried out to a single department in an organization). The aim of this paper is to distinguish among different complexity tackling strategies, to clarify how each strategy works, and how it contributes to reduce the complexity of the objects involved in a modeling process: the entity being studied; the (mental) model that has been conceptualized; the representations of this model. It is believed that to be aware of the strategies described in this paper will contribute to a better understanding of the entities of interest and to a better performance of IS developers. It should be noted that the examples used in this paper mainly correspond to a situation where it is being created (conceptualized) a model of an entity that already exists. None of the examples attempted to illustrate a situation where the model corresponds to an entity that is being designed, so, it doesn’t exist yet. In such case other strategies could be considered (e.g., the use of design patterns [23], [24]) that have been considered out of the scope of this paper.

REFERENCES 1.

Carvalho, J. and L. Amaral, Matriz de Actividades: Um Enquadramento Conceptual para as Actividades de Planeamento e Desenvolvimento de Sistemas de Informação. Sistemas de Informação, 1993 (1): p. 37-48.

2.

Carvalho, J., A Disciplina de Sistemas de Informação II. 1995, Universidade do Minho, Portugal.

3.

Yeh, R.T., et al., Software Requirements: New Directions and Perspectives, in Vick, C.R. and C.V. Ramamoorthy, Handbook of software Engineering, Van Nostrand Reinhold Company, 1984. 1984. p. 519-543.

4.

Coad, P. and E. Yourdon, Object-Oriented Analysis. 2nd ed. 1991: Yourdon Press/Prentice-Hall.

5.

Brinkkemper, S., Formalisation of Information Systems Modelling. 1990, Thesis Publishers, Amsterdam, Holanda: University of Nijmegen, Holanda.

6.

Carvalho, J., BMKB (Business Meta Knowledge Base): A Repository of Models for Assisting the Management and Development of Organizational Information Systems. 1991: Ph.D. Thesis, UMIST University of Manchester Institute of Science and Technology, UK.

7.

Martin, J., Recommended Diagramming Standards for Analysts and Programmers: A Basis for Automation. 1987, Prentice-Hall.

8.

Nijssen, G.M. and T.A. Halpin, Conceptual Schema and Relational Database Design: A Fact Oriented Approach. 1989: Prentice-Hall.

9.

Chen, P.P., The Entity-Relationship Model: Towards an Unified View of Data. ACM Transactions on Database Systems, 1976. 1 (1).

6 10.

Downs, E., P. Clare, and I. Coe, Structured Systems Analysis and Design Method. 2nd ed. 1992: Prentice Hall.

11.

Yourdon, E., Modern Structured Analysis. 1989: Prentice-Hall.

12.

Rumbaugh, J., I. Jacobson, and G. Booch, The Unified Modeling Language Reference Manual. 1999: Addison-Wesley.

13.

Eriksson, H.-E. and M. Penker, Business Modeling with UML: Business Patterns at Work. 2000: John Wiley & Sons.

14.

Chaves, A.P. and J. Carvalho, Expressiveness and Legibility in Conceptual Modelling: A Comparison of Three Technique, in Siau, K. e Y. Wand, Proceedings of the workshop “EMMSAD’96 Evaluation of Modeling Methods in Systems Analysis and Design”, Heraklion, Greece, 20-21 May 1996. p. D1-D13.

15.

Le Moigne, J.-L., La Théorie du Système Général: Théorie de la Modélisation. 1977: Presses Universitaires de France.

16.

Carvalho, J. Information System? Which One Do you Mean? Proceedings of "ISCO 4 - Information Systems Concepts: An Integrated Discipline Emerging", Leiden, Holland, 20-22 September 1999.

17.

DeMarco, T., Structured Analysis and Systems Specification. 1979: Yourdon Press.

18.

Martin, J., Information Engineering - Volume 2. 1986, SAVANT, Carnforth, UK.

19.

Ross, D.T., Structured Analysis (SA): A Language for Communicating Ideas. 1977, IEEE Transactions on Software Engineering, Vol. 3, Nº 1: G-3. p. 1634.

20.

Yourdon, E. and L.L. Constantine, Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. 1979: Prentice-Hall.

21.

KBSI, IDEF Family of Methods, http://www.idef.com, 2000.

22.

NIST, N.I.o.S.a.T.-. Integration Definition for Function Modelling (IDEF0). 1993.

23.

Evitts, P., A UML Pattern Language. 2000: Macmillan.

24.

Gabriel, R.P., Patterns of Software: Tales from the Software Community. 1996: Oxford University Press.