Information Systems Development Methodologies: Are you being served? Abstract Michael Boahene Simsion Bowles and Associates Melbourne, Australia The scope of practitioners concerns in the development of information systems is not being adequately addressed by current SDLC based methodologies. This paper introduces a concept of how to create an ISD methodology which is capable of serving practitioners needs beyond the current limitations of SDLC based methodologies. Keywords IS Development Strategies, IS Life Cycle Activities, Software Engineering INTRODUCTION A casual look at Information Technology and Information Systems job advertisements in any newspaper in Australia today, reveals an increasing interest by employers in potential employees knowledge about the processes of System Development Life Cycles (SDLCs). While this recognition of the importance of knowledge regarding the processes of Information Systems Development (ISD) is encouraging, it is very disturbing to observe that SDLC should be taken to represent the defacto approach by which ISD is undertaken. Although usually referred to in these advertisements as if it were state of the art in the evolution of ISD methodologies, SDLC in fact represents one of the earliest attempts to codify a concept of the activities undertaken when developing software. It adopts a stance which encourages a naive, although seductive, rationality and objectivity regarding the development of information systems, entrenching a command and control (rather than innovative) behaviour, thereby exacerbating the problems faced by ISD practitioners. In fact, it might be considered in the same vintage as the Ford Model T assembly line process. The undeserving status of SDLC is further boosted by the current popularity of the software engineering approach to systems development, which takes as its fundamental anchors, a systematic view of process (using variations of the SDLC s phases) and a static view of the environment in which information systems are developed and applied. The methodologies and benchmarks generated by this engineering view are further legitimised by their proponents as world s best practice, despite its fundamentally flawed view of the environment. This case study represents an attempt to identify the productivity inhibiting factors affecting IS development, and create a methodological framework which is capable of serving practitioners beyond the limitations of the variations of the SDLC. It identifies the concerns and dilemmas that face IS practitioners, then advocates the need for a methodological framework (rather than a ready made process) which can assist in the creation of an approach to support IS development. This leads into discussing what such a framework should contain in order to serve the needs of practitioners, as they Proc. 10 th Australasian Conference on Information Systems, 1999 88
face the practical dilemmas in the environment. Throughout this report, the SDLC is assessed in light of its ability to serve practitioners needs. WHAT ARE PRACTITIONERS CONCERNS? Conceptualising the environment In order to identify what is likely to concern practitioners when developing an information system, we first have to appreciate the environment and atmosphere in which the IS development activity takes place. The environment is the source from which a scope of interest can be drawn, a limit to our capability demonstrated and all performance attributed, hence its fundamental importance cannot be over stated. This environment is not unlike an ecosystem, with its numerous elements and factors interacting in a complicated web which forms forces that shape it. This dynamic environment is, however, more complicated than a natural ecosystem because it is inhabited by humans who have a consciousness, and usually act in a variety of ways to serve interests which are not always unitary. In describing the environment in which the activity of IS development takes place, table 1 has been used to list the major elements and their associated characteristics: Elements Staff Stake holders Power/ Authority Information flow Process/ Procedure Technology Requirements Characteristics Skills, Background knowledge, Experience Problems, Interests, Expectations Organisation structure, Influence Coordination, Terms, Communication types, Communication media Sequence of steps, Tasks, Deliverables Computer language, Hardware platform, Tools Stated, implied, anticipated and non-stated needs Table 1: Elements and characteristics of an ISD Environment The characteristics (which may be active or dormant) are usually the target of forces (intended or unintended), that invariably shape the environment. The dynamic action of the forces collectively creates the atmosphere (or image) of the environment. To aid with conceptualising the environment, the following model could be used to assess its state and determine initiatives to be undertaken in order to steer the environment towards a desired target state. 89
Foundation Structures Aesthetics Identifies all the activities in the environment which are aimed at improving the mental capacity of team members to enable sound judgement in reducing uncertainty when faced with a problem situation. Capture all conceptions and activities in the environment which are aimed at setting boundaries or limits to operation within the environment. Consists of all the elements and activities aimed at positively elevating both the internal and external profile of the environment. Table 2 : ISD environment assessment model Core concerns of IS practitioners The concerns faced by practitioners have been well documented over the years in numerous books and articles. See Avison and Fitzgerald (1995) for a recent account. As a practical illustration of what practitioners are likely to be concerned with, following is a summary of the results of an investigation I recently conducted into productivity inhibiting factors in a segment of the IT division of a large organisation. The data was collected through questionnaires, individual interviews, work group sessions and documentation research. Pre-set deadlines were the main driver of all work. The effect of completing a delivery on time at all cost, without adequate regard for completeness, effectiveness and efficiency of the resulting product, spawned a vicious cycle of reactive maintenance. Focus on the client who provides the requirement is disproportionately allocated compared with other Stake holders. This provides a false comfort zone in which the visible clients requirements are taken as complete and then simply translated into computer based representations. Process compliance (rather than staff capability to understand and interpret requirements) is over emphasised as the main instrument of assurance for completing a release. As a result, staff do not particularly feel a responsibility for delivery outcomes. They adhere to process as a form of defence for their actions. An apparent separation of quality and functionality as end deliverables, promotes an either/or mentality which makes it acceptable to view product quality as distinct from functionality. The absence of a coherent framework to guide decision making beyond conformance to process created discontinuities within and between teams, with the result that Herculean effort or authority based decisions are required to complete work. Suggested remedies to reported concerns usually tend to be limited evermore to the mechanics and controls of methods rather than expressions that deepen knowledge about the uncertainties inherent in the IS development phenomena. Although the problems above, were visible through the processes used, in fact, the causes could be attributed to the underlying assumptions about Staff knowledge, Stake holders, Power/Authority and Requirements that prevailed in the environment. WHY DOES IS DEVELOPMENT NEED AN APPROACH? In appreciating the dynamic nature of the environment in which IS development takes place, it becomes apparent that a direction (for the actions) is needed to motivate development activities toward a particular target. It would be a relatively simple matter if all the elements in the environment 90
were physical or natural and could be manipulated with certain predictable responses. In contrast however, our IS development environment consists of physical, human and abstract elements; this mix of elements providing our environment with a potential which is not available in predictable environments. Consequently, there exists an opportunity to perform and be perceived uniquely. The performance produced by the environment depends on the way its elements interact. What is an approach? The way in which the elements interact to perform is what I term an approach. An approach requires purpose, organisation, sequencing, incentive and agreement, but that is not all. Of course, there are varying degrees of these attributes evident in the functioning of any approach. Were the attributes invariant however, then all approaches would be indistinguishable. However, as pointed out by Hirschheim et. al. (1995), there are distinguishable differences between the various approaches to IS development and their consequent effects. The source of these differences lies in the consciousness that makes us aware of situations and the paradigmatic assumptions that fuel our thinking, which result in the actions that we take when developing information systems. An approach therefore, above all, needs to encapsulate consciousness generating knowledge; the kind of knowledge and awareness that Kim Caputo (1998) has characterised as the deeply embedded muscles that need to be flexed by a dancer to demonstrate graceful and seemingly easy movements. This, however, is what is sorely lacking in SDLC based methodologies. The knowledge will be related to the environment (ie. its elements and characteristics) and atmosphere in which the human activity of IS development takes place. This knowledge ought to help us in knowing why, knowing how and knowing what. It ought to help us to find out the constraints and opportunities which exist in the environment and further more, provide us with the consciousness that makes us aware of our situation in a unique way. Put simply, a methodology in action is what I have described above as an approach. Is a methodology any use? A methodology therefore, will only be useful to its users if it coherently addresses the questions of how to organise and conduct an inquiry so that interventions into problem situations reduce, if not eliminate, the uncertainties inherent in the problem situation and furthermore enable its users (ie. practitioners) to leverage their experiences. While the choices available to intervene in a problem situation are limited only by our imagination, different choices will yield different results, whether those results are anticipated or not. A methodology that is likely to be effective will be one that addresses (or at least appreciates) the concerns of IS development in that environment. The approach will have to enable a clear vision through a window broad enough to accommodate the dilemmas that its users are likely to face. It will need to be able to manage the volatility of the elements and the impact of forces in the environment. JUSTIFICATION FOR A FRAMEWORK 91
Previous works on information systems research have provided insight and broadened our knowledge about the influence of the paradigmatic assumptions that feed our thinking about IS development (Jackson, 1991, Dalbom & Mathiesen,1995, Hirschheim et. al,1995). Following a critical analysis of each form of research into the development of ISD methodologies, Lucas Jr.(1981) concluded that there are no universally prescribed controls (that can be written into processes and procedures), that will deal with the variability of the many influential factors prevalent in any particular environment. However, in such a dynamic environment, it is possible to draw on models of reference as circumstances and context demand. These models of reference are what collectively form a framework. The two essential parts of such a framework of reference which are suitable for managing uncertainty in the environment are: knowledge that supports inquiry (ie. the finding out) and knowledge that facilitates intervention (ie. the solving) and supports anticipating its likely effects An approach created from such a framework would necessarily have to go beyond the deterministic view which is so often the limit of the SDLC based approaches, to provide a means of viewing the changing environment in a systemic way and learning about it to understand our situation clearly. In contributing to this accumulating body of knowledge, the framework introduced here aims to assist with the creation of a theoretically based and practically useful ISD methodological framework which would in essence support the observation by Lucas Jr. WHAT MIGHT A USER OF AN ISD METHODOLOGY EXPECT? So far, I have drawn attention to the existence of an environment and an atmosphere in which IS development takes place, and argued that a conscious approach (which is sometimes loosely but erroneously referred to as method or process ) is required to initiate and manage the forces which affect the elements in the environment to produce required outcomes. Drawing from the active forces which cause issues, dilemmas and opportunities to become apparent in the environment, it could be deduced that a would-be practitioner in the environment would want an approach to: enable them to meet and exceed expectations of their work requirements, without undue stress enable them to know how to find out (inquire) about the nature of a problem situation and make effective intervention choices enable them to know who the interested parties are and how they could be affected enable them to know how to meld quality with function so that their interventions are complete, efficient and effective contain points of reference where all team members can identify the focus or essence of their task deliverables with respect to the requirements provided for a particular assignment 92
HOW CAN A METHODOLOGY MEET THESE EXPECTATIONS? (Hornby et. al. 1992) summarise the behaviour and attitudes of practitioners as follows: They do not necessarily follow through the cascading waterfall methods by the book, although the notion of phases in the life cycle is certainly used. Their approach seems to be related to experience. On human and organisational issues, Hornby et. al. go on further to observe that: Analysts do not claim to have knowledge or understanding of human and organisational issues in IT systems and there is no evidence that they are encouraged to or rewarded for considering such issues. In fact it could be said that the reward and control systems within which analysts work actively encourage them not to consider them. These observations serve to demonstrate that practitioners need supportive information to facilitate knowledge acquisition, information gathering and analysis (ie. the know why ), not just prescriptive processes and technical information. If a methodology does not adequately support this need which enables an effective management of the dynamic IS development phenomena, then other ad hoc ways are likely to be used to compensate for its deficiencies. A methodological framework that is likely to provide this comprehensive nucleus from which practitioners (inquiry and intervention) capability could be generated and sustained in line with the dynamic environment, would have to include Background knowledge, Ideal models, Process, Process management, Transformation management and Tools. The components of the framework, in effect, enable a panoramic view of the environment in which IS development takes place. A large part of the framework consists of abstract ideas which need to be recognised and understood by practitioners in order to harness its capabilities. After all, an ISD methodology is essentially an amalgam of ideas supported by material resources. However, as with any dynamic environment, the ideas are continually changing. Figure 1 below shows the relative potency and stability (indicating susceptibility to change) of ideas in each of the components of the framework on a continuum. Stable Volatile Background Knowledge Ideal Models Process Process Management Transformation Management Tools Figure 1: Framework component stability in ISD environment Background knowledge There are a number of methods and techniques that can be utilised in the activities of finding out about problem situations. Background knowledge however, remains a prerequisite for recognising and interpreting findings of significance and relevance no matter what method or technique is used. Recognition of the pivotal role played by background knowledge in shaping the rest of the framework is an enlightening experience. Background knowledge represents the material that fuels our thinking about a particular situation and forms the basis of our judgement about what is considered relevant and critical and what is not. It is so important because the way we think influences what we do. 93
Underlying Assumptions The underlying assumptions made by practitioners are probably the most difficult to surface and critically evaluate. These assumptions largely create and sustain our world view. The world view forms the window through which we see situations and explains how we perceive them. For instance, we may hold assumptions that make us see a world which looks as follows: the essence of our profession is IT specialisation the development of information systems is similar to assembly line manufacturing or the engineering of a bridge our customers provide us with what they want and we develop it for them an organisation exhibits a unifying, rational, goal seeking behaviour Underlying assumptions are usually unwritten and hardly ever surfaced for critical evaluation by most SDLC based methodologies. The importance of the recognition of underlying assumptions as part of Background knowledge in this framework is to provide an avenue through which these assumptions can be surfaced and subjected to critical debate. The assumptions we hold may be found to be the source of all unfulfilled expectations. Beliefs and Values Beliefs are the inferences of truths that we hold in esteem and values help us to justify and uphold those beliefs. If our assumptions are held as true, then their inferences and deductions will form the beliefs that we hold in esteem. These beliefs affect our attitude to and perception of the ISD phenomena and the environment in which it occurs. As a consequence of the assumptions stated above, we may form beliefs such as: our goal as IT specialists is technical excellence, which can be measured by product conformance to requirement specifications we only need to translate our customers specified requirements into computer based representations standards compliance and process adherence will improve our work throughput However, in practice, our primary role within organisations is to develop and manage information systems our customers do not fully define their requirements a product s technical excellence does not necessarily mean that the customer s needs have been satisfied. Nature of information systems If we take our primary role within organisations to be one of developing and managing information systems, it is important, as part of our background knowledge, to be clear about what an information system is, the basic elements that shape it and the factors that influence its nature. Checkland and Howell (1998) provide an enlightening account on this subject. 94
The purpose of any information system is to serve a community of users who rely on it for the operation of a purposeful activity. The nature of an information system that truly fits the bill can be revealed by finding out about: what will constitute information in that particular context the boundary of the system and its interaction with other systems (social and technical) a concept of the organisation and technological choices Variety of application systems embodied in information systems The information systems operating in many organisations today are supported by computers. The part of the information system that is computer-based is the application system. As professionals who are viewed as having the knowledge and skills to create these information systems, knowledge about the variety and mix of the computer-based representations are vital. While there is considerable variation of purpose, structure, scope and sophistication between information systems, they all exhibit one or more of the following core characteristics: transaction processing, process automation and user interactivity. These underlying characteristics are manifest in all types of information systems; from rocket launchers to accounting packages. Theoretical influences If the Software Engineering Institute s definitions of methodology and process, as published by Paulk et. al. (1995) are to be taken seriously by a practitioner, then the activity of IS development would be reduced to a series of context independent and value free steps that in principle are repeatable by anyone who cares to follow them. This assertion would not be controversial if the environment was static and therefore determinate and the dilemmas of IS development, value free. However, as discussed previously, this is not what a practitioner experiences on a day to day basis. Furthermore, a dictionary definition of a methodology as the science of method, conjures notions of thought and boundary. Therefore, as pointed out by Hirschheim et al. (1995), an IS development methodology may be described as: an organised collection of concepts, methods, beliefs, values and normative principles supported by material resources Thought is usually based on some philosophical view, and the boundary drawn from the dilemmas of managing within the environment. Assuming there is a philosophical view that supports the engineering approaches (of which the SDLC phases is a corner stone), it could be said to be deterministic and the boundary, narrowly focused, concentrating on the development means and giving little consideration for problem or effect uncertainty, and therefore unlikely to effectively address the issues and dilemmas experienced in the environment in which the development of information systems take place. Terms The field of IS development is severely hampered by the limitation of meaning derived from the everyday use of some representative words in the English language. Some of the field s most important concepts are only partially explained when the meanings attributed to them are relied upon. 95
For instance, the IEEE- STD-610 defines process as a sequence of steps performed for a given purpose. In practice however, process is used in several contexts ranging from instructions to concepts. This makes it difficult to unequivocally grasp its intent in print. However, teamwork (which is the hallmark of IS development) relies heavily on effective communication. A coordinated team effort requires socially constructed planks such as a language which promotes a common understanding upon which to facilitate inquiry and intervention. The planks form the bridges which hold together the participation of coalitions of interested parties and the rest of the elements in the environment in a cohesive whole to progress through the development of an information system. Wherever such planks are non existent or brittle ( as in the case of process ), effective decision making is inhibited. This is usually manifest in the considerable amount of effort required to keep releases on track. Ideal models The lack of attention to ideal models for information systems in many current ISD methodologies is perhaps the biggest omission that holds them back from being of much practical use beyond the tools and techniques they offer. Ideal models are unconstrained abstractions of views of a desired outcome. Termed mental models by Senge (1990), they can be seen as a holy grail that all can strive for while at the same time providing the minimum for an outcome to be considered as an information system. A useful analogy for information systems ideal models is the human form. When a child is born, we expect it to have two legs, arms, eyes, a head, nose, mouth and so on. This unconstrained structure represents the ideal model that we have come to expect of the human form. In a similar way, an ideal model of an information system can be expected to have as its building blocks, inputs, outputs, data structures, processing models, controls (including system and operational controls), technology and a variety of users. Ideal models can be represented as standards, archetypes and normative principles. Such models provide the basis for understanding and identifying what is missing, when requirements are analysed. Without ideal models, a practitioner is not systemically reminded of all aspects of the target information system which need to be considered, and thus the completeness of requirements and subsequent analysis is left to chance. Process The grouping of activities form process steps which generally indicate a progression through the transformation of requirements into expected outcomes. This logical categorisation of activities (known as phases) from start-to-finish of a development exercise is what the SDLC represents. They are usually documented as processes, procedures and instructions. Unfortunately, knowing about the existence of phases and their sub categories, and what to do in each is hardly a revelation. Documenting what to do only provides the practitioner with a know what. The use of a methodology which has a disproportionate emphasis on the know what (which unfortunately, is the hallmark of many SDLC based methodologies) will therefore not surprisingly produce information systems with disappointing effects as the section on IS practitioner concerns above, pointed out. 96
Taking the purpose of our effort to be the reduction of uncertainty, both in the problem situation and the development undertaking, there is a dense web of inter-relationships between task type, focus of effort, skills and knowledge that affect the quality of the product. Attention to these interrelationships is where the know why and know how lies. These observations have further implications for process improvement in IT organisations, since even in the engineering and manufacturing traditions from which the concept of process has been borrowed, its relevance is limited to the replication of exact copies of a particular product. To make a better product, engineers in these traditions, first have to reconsider their assumptions and form different appreciations of previously taken for granted possibilities and relationships in the target environment. In other words, they rethink and see their situation differently and then devise a different way (which becomes the new process) of creating the product. Tinkering with an established process without a rethink of its associated underlying assumptions, at best, only yields marginal gains. Process management This component of the framework probably enjoys the most attention today because of the rise in the influence of risk mitigation disciplines (such as quality assurance, configuration management and metrics) over process. These disciplines are seen as omissions from the original focus of SDLC and continue to be outside the core of most engineering based methodologies today. The focus of interest for any methodology derived from this framework would integrate estimation, risk identification, assessment and mitigation into the approach rather than as extensions. This will use the techniques of quality assurance, configuration management, monitoring, measurement and control, in order to reduce uncertainty about the problem, development means and target system s effect. Transformation management The primary role of a methodology is to support the transformation of clients needs into target information systems. The transformation uses the clients requirements and components of the framework as ingredients in the IS development effort. The utilisation of the various components of the framework (to generate situational knowledge) supports the development s progression from requirements gathering through to implementation and any subsequent changes. Applicable Background knowledge and Ideal models especially, form the main inputs that initiate and fuel the analysis and synthesis of client supplied requirements. The analysis yields stated, implied and anticipated requirements that encompass the problem situation in the environment, and the synthesis melds these requirements with background and situational knowledge into representations of the ideal models. Tools Tools support techniques, methods and normative principles and enforce standards and procedures which are used in the development of information systems. They are generally viewed as context independent and value free, however, they usually exhibit the limitations of the assumptions of the techniques and methods they are built to support. It is therefore important to be aware of the assumptions and limitations when selecting a tool, otherwise a target output could be unduly influenced. 97
WHAT COULD BE GAINED FROM USING SUCH A FRAMEWORK? It is anticipated that by adopting such a panoramic framework to develop an applicable methodology, the following benefits may be gained: a systemic methodology from which an approach can be tailored to a problem situation so that it facilitates IS development and reduces work pressure provision of a basis for contextual understanding of a problem situation improved shareable team understanding (ie. group commonsense) needed for progressing through the activities of IS development provision of requirements and expectations traceability leading to product completeness CONCLUSION The scope of practitioners focus encompasses information systems rather than mere software development. As such, ISD methodologies need to move beyond their current focus on a series of steps, techniques and tools and take the potential impact of Background knowledge and Ideal models seriously if they are to provide practitioners with the means to address the issues, dilemmas and opportunities they face in their work environment. Stamper (1973) in Miles (1987) captured the sentiment of issues and dilemmas that were being experienced within many organisations with the following quote, Information technology is not being used effectively to solve organisational problems. On one side stand the technologists most of whom have no idea of the complexity of organisations; on the other side stand the managers and administrators, unable to translate their problems into feasible demands upon technology; between them a river of mistrust flows through a chasm of misunderstanding. Since then, there have been a number of generations and refinements to the SDLC, which was at that time and still is, the dominant way of developing information systems. If this sentiment still sounds contemporary in our environment, then be reminded by Kahneman & Tversky (1973) who are quoted by Makridakis & Wheelwright (1989) that, Errors of judgement are often systematic rather than random, manifesting bias rather than confusion.... The framework introduced in this case study delves into the root causes of the misunderstanding referred to by Stamper. It departs from the rational and objective assumptions upon which SDLC based methodologies have been built and embraces the concept of a dynamic environment. It provides what Flood (1999, to be published in July) terms the prism view, for a panoramic look at the ISD environment and problem situations, with Background knowledge as its linchpin. REFERENCES Avison, D. E, Fitzgerald G. (1995) Information Systems Development : Methodologies, Techniques and Tools, McGraw-Hill 98
Caputo, K. (1998) CMM Implementation: Choreographing Software Process Improvement, Addison-Wesley Checkland, P. B., Howell, S. (1998) Information, Systems and Information Systems: Making sense of the field, John Wiley & Sons Dalbom, B., Mathiesen, L (1995) Computers in context: Philosophy and practice of System Design, NCC Blackwell Delvin, K. (1997) Goodbye Descartes: The end of logic and the search for a new cosmology of the mind, John Wiley & Sons Hirschheim R., Klein H. K, Lyytinen K. (1995) Information Systems Development and Data Modeling : Conceptual and Philosophical Foundations, Cambridge University Press Hornby P. et. al.(1992) Human and Organizational issues in Information Systems Development, Information Technology, vol. 11, no. 3 Humphrey, W. S. (1989), Managing the Software Process, Addison-Wesley Jackson, M. C., (1991), Systems Methodology for the Management Sciences, Plenum Press Lucas Jr., H. (1981), Implementation : The Key to Successful Information Systems,Columbia University Press Makridakis, S., Wheelwright, S. C. (1989) Forecasting Methods for Management, John Wiley & Sons Miles, R. K. (1987) The Soft Systems Methodology : A Practical Framework for Computer Systems Analysis, Doctoral thesis Paulk, M. C., et. al.( 1995), The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley Senge, P. (1995) The fifth discipline - The art and practice of the learning organization, Random House Turner, D., Crawford, M. (1996) Competencies for corporate change, HRMonthly, May Winter M. C., Brown D. H. Checkland P. B. (1995), A role for soft systems methodology in information systems development, European Journal of Information Systems COPYRIGHT Michael Boahene 1999. The author assigns to ACIS and educational and non-profit institutions a non-exclusive licence to use this document for personal use in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author also grant non-exclusive licence to ACIS to publish this document in full in the Conference Papers and Proceedings. Those documents may be published on the World Wide Web, CD-ROM, in printed form, and on mirror sites on the World Wide Web. Any other usage is prohibited without the express permission of the author. 99