Fundamental Ethics Approach in Information Systems Development

Shane Molinari, MSc, CISSP, PMP, ITSM, SSMBB Principal, BCM Professionals

Fundamental Ethics Approach in Information Systems Development A lack of an effective analogy exists forcing organizations to realize new moral values, invent new moral principles, and develop new policies. Where most organizations focus on technical issues regarding systems analysis and design approaches, the focus lacks the ethical challenges faced not only within the vendor-client relationship, but moreover the relationship between the product and the general public. Furthermore, this document will also offer suggestions that include professional awareness, methods for resolving non-technical ethics questions, and proactive skills to reduce potentially recurring ethical problems. Professionals involved in information systems (ISs) development are confronted by and significantly affected by ethically volatile situations. However, much of the work in computer ethics has seemingly limited input from the IS and computer science disciplines. Although there are suggestions regarding how successful IS development tasks could employ a fundamental code of ethics, there are some important assumptions to be considered: 1. Both deontological (the metaphysical study of the sinister nature of being and existence) and consequential theories of ethics are important. (Johnson, 2004) 2. Although we must often follow rules, the consequences help to formulate rules, and facilitate decision-making when rules clash. 3. Ethical principles are objective not subjective. It is common knowledge that there are several approaches to IS development. However, few deal sufficiently with the ethical dimensions of systems development. They point out that those criticisms exist because most organizations have adopted a development methodology, which tends to stress the formal and technical aspects. Moreover, human and social organization aspects are frequently overlooked. However, this perspective seems to occur in the event of system failures or program underperformance.

Page 1 of 10

There are a number of concerning questions that systems analysts may face when undertaking a development project, using a methodological approach:

Whose ethical perspective will dominate the situation study and the IS development? Will ethical viewpoints be included in the study? What methodology should be used for the study? What approach should the analyst use if an obvious conflict of interests exists?

Unfortunately, most organizations fail to commit to a particular ethical stance or offer any means of discussing or resolving many of the ethical dilemmas faced during systems development. Although an ethical sensitivity investigation is undertaken, too many times an ethically defensible position unclear is derived. Nonetheless, improved methodologies must deal with these criticisms. There are six areas of concern that focus upon the public interest, duty to the employer and clients, duty to the profession, and professional competence and integrity: 1. Priorities 2. Competence 3. Honesty 4. Social Implications 5. Professional Development 6. Information Technology Profession Equally important, there exists a series of core modules that coincide with developmental project management steps including: 1. Feasibility study: a. To determine whether systems can be developed to meet defined business and technical objectives within specified financial and operational constraints.

Page 2 of 10

2. Requirement analysis: a. To determine the application scope; b. To establish how to integrate IT with other needs; c. To form an overall view of system costs and benefits; d. To confirm the viability of continuing further; e. To achieve user buy-in of the requirement. 3. Requirement specification: a. To produce a complete specification that informs the subsequent logical systems specification. 4. Logical systems specification: a. To enable management to select the technical environment that offers the best value for the money; b. To provide an independent non-procedural specification of system functionality. 5. Physical design module: a. To develop a physical design that defines data, processes, inputs and outputs whilst incorporating installation standards; b. To form the basis for system construction. (Whitten et al, 2004, pp 186-267)

In addition of the aforementioned modules, there are three modeling perspectives: 1. Functions: this is an attempt to capture the user's view of system processing. Techniques used include data flow modeling. 2. Events: these are business activities that trigger processes to update system data. Techniques involved include entity life histories and affect correspondence diagrams. 3. Data: this is a description of the data used in the system utilizing a logical data model.

Page 3 of 10

Product Breakdown Structure A product breakdown structure (PBS) is an exhaustive, hierarchical tree structure of components that make up a project deliverable, arranged in whole-part relationships including products and processes. (Fact-Index, 2004)

Products Products are defined within a product breakdown structure hierarchy, the top level of which has three elements: 1. Management products 2. Technical products 3. Quality products These three categories are designed to be complementary to ensure that a high quality solution is provided in a managed and controlled way. Management products are used in planning and controlling the project, technical products document how the project proposes to realize the project objectives, and quality projects demonstrate how quality has been built into the system. However, some product breakdown structures are organizationally oriented, and therefore do not appear to go beyond the surroundings of the organization. This approach seemingly demonstrates the well being of many individuals as being at risk, unless an ethically sensitive horizon is established for the scope of consideration. The scope of consideration is an ethical hot-spot that is influenced by the identification and involvement of all stakeholders and those beyond the organizational boundary. In order to make clearer some of the issues regarding stakeholders, it would prove useful to identify four principal groups: 1. Developers who develop and sell the system 2. Buyers who purchase and own the system

Page 4 of 10

3. Users who use the system 4. Uncertainty, comprising anyone affected by the use of the system However, these groups are clearly not mutually exclusive. The developers and buyers could be the same people, and might also be users of the system. Any of the first three groups could also overlap with uncertainty. This identification assists in the clarification responsibilities and tensions in the software development enterprise. The basic tension is clearly between cost, on the one hand, and reliability and ease of use on the other. The more time spent developing a product, the better it can be, but the more expensive it will be. Typically there will be some trade-off between these two. The important question then is what criteria should be used to determine where the line will be drawn. Collins et al. suggest three: 1. Do not increase harm to the least advantaged 2. Do not risk increasing harm in an already risky environment 3. Use the publicity test for difficult trade-offs The first criterion in most cases would refer to members of uncertainty, that is, those who are affected by the system but who may derive little or no benefit from it. The second criterion is unlikely to help much in identifying who will be harmed, but it does emphasize that more care needs to be taken in some situations than in others. The third criterion are then trade-offs between financial benefits to the one party and personal (i.e. non-financial) harm to another party should be made on the basis of a costbenefit ratio that, if made public, would not outrage most members of the public (Collins et al., 1995, p. 86). Identifying the stakeholders undoubtedly aids in making some of the issues clearer. There is, however, some problems still exist with the ideas of "distant stakeholders" and the "ethically sensitive horizon". Nevertheless, this problem is not new, and any consequentialist theory of ethics must face it - actions are to be judged right or wrong based on their consequences. (Britannica, 2004)

Page 5 of 10

What's more, although some argue that individuals should be free to take actions that affect only themselves, it is acknowledged that most actions can and sometimes do affect others. Applying this to the software development environment, perhaps the horizon should be set so that all those affected by the software "directly and in the first instance", or who are primarily affected, have their interests taken into account. For example, not only should the interests of those using an unfriendly ATM be taken into account, but also the interests of their families (who generally receive the brunt of the of the unsuccessful users annoyance). While this serves as a vague ethical guide, there may be different stakeholders and horizons at each phase of the development process to better maintain a sense of balancing goals with social responsibilities. For example, at the feasibility study phase there will be a host of social and environment concerns involving many groups in society, while at the logical system phase the focus will be more on management, technical staff, users and company shareholders.

Process For practical purposes, it is clear that we must follow valid rules. After all, it seems obvious that rules are needed because we cannot always consider all likely outcomes of an action. Equally important, consequences must be taken into account since rules sometimes clash, and need to be overridden for a greater good. The deliberation here is the consequence of the degree of dependency on regulations. Policies cannot examine the consequences of all of our actions to see whether they cause, or are likely to cause, more or less harm than alternative actions. This approach would prevent us from accomplishing anything. Therefore, it should be said that during important instances, particularly when rules clash, such deliberations should be considered. In view of what has been discussed, it is important to also address both the product and the process simultaneously.

Page 6 of 10

The product breakdown structure provides the necessary drive to deal with issues in a certain way. The totality of these products needs to be considered, in view of their powerful influence in the development. Moreover, consideration must also be given to how the systems developers should think when carrying out a variety of development tasks. Doing so emphasizes the importance of quality control encompassing the whole IS development process and therefore not simply to be considered at discrete points within the process. Product descriptions are part used to monitor progress and success of the project. Including quality in each description ensures that it permeates the whole process and promotes a quality way of life throughout the development team. Similarly, ethical and societal consideration should be given during the whole process. In many cases, quality issues overlap with ethical ones, for example, in safety critical systems. The purpose here is not definitive accuracy, but rather a possible approach to adding checkpoint questions where they would be most effective. Application of technical environment options, within logical system specifications, sets the standards for the user environment within the particular project. This includes ergonomic details and system based requirements. At this juncture, some ethical criteria questions could include: Does the system protect and promote the health and safety of those affected by it? Is the application style such that integrity and security of individuals is not compromised? Am I happy that this product is suitable? Has a walk-through of the application style taken place? Is the working environment enhanced?

For example, moving from the data flow diagram to the required logical data model reduces the requirement definition by removing data redundancy and irrelevance. On the other hand, there is also the issue of ethical and societal proof of included data item(s). Both sides could be addressed by developing a standard reference model that enables the ethically and socially charged items to be

Page 7 of 10

analytically identified. Afterwards, selecting a course of action would be based on balanced and complete information. Rogerson and Bynum (1995) developed a four-perspectives analysis decision-making process, which results in a tentative action plan. They stated that it is essential that an ethical control loop exist providing the opportunity to review the decision made - before the action takes place. Furthermore, they stated that since scientific nature encourages rational logic, it is worth considering incorporating ethical modeling. This process is based on logical a breakdown that identifies the "best" way of satisfying a user requirement. Moreover, it is oriented to the final product with the analytical passage simply being the means to that outcome. A consequentialist approach is attractive in this context. Indeed, it might be possible to develop an ethical modeling approach based on Bentham's hedonistic calculus. (Bentham, 2004) The seven aspects in the calculus used to compare relative outcomes can be reinterpreted in six terms more appropriate for ISs development as: 1. The value of the benefit 2. The duration of the benefit 3. The degree of certainty in benefit realization 4. When the benefit will be realized 5. Whether the system will lead to secondary or indirect benefits the individuals, business and communities affected. Note that the last two items would require consideration of all stakeholders, alterations to community culture, and effects upon environment. This could result in a considerable reduction in complexity, using checklists. At this point, it would seem that the consequentialist approach has merit since it links the ethical character of actions to their practical result. However, this can be extremely difficult. After all, it would require not only careful analysis of instantaneous consequences, but also an uncovering of the

Page 8 of 10

long-term results. This is mainly relevant for ISs where systems interact resulting in long-term effects that are difficult to predict and measure.

Conclusion This paper has discussed the ethical problems associated with ISs development. Seemingly, more research is needed in this area. It is has been demonstrated that approaches exist that that lack effective ethical considerations. Principled improvement of development methods must be carefully undertaken and validated. Only then, will there be an increase in ethically sensitive ISs.

Page 9 of 10

References:

Bentham. (2004). Benthams An Introduction to the Principles of Morals and Legislation. Retrieved from http://www.angelfire.com/md2/timewarp/bentham.html on 4 October 2004 Britannica. (2004) Retrieved from http://concise.britannica.com/ebc/article?tocId=9363949 on October 4, 2004 Collins, W., Miller, K., Speilman, B., Wherry, P. (Vol. 37, No. 1, January 1994, pp 81-91). How Good is Good Enough? An Ethical Analysis of Software Construction and Use. Communications of the ACM. Johnson, R. (2004). Supplement to the Encyclopedia of Philosophy. http://showme.missouri.edu/~philrnj/deon.html 5 October 2004 Product Breakdown Structure. (2004). Retrieved from http://www.fact-index.com/ on 4 October 2004 Rogerson, S., Bynum, T.W, "1995", "Towards ethically sensitive IS/IT projected related decision making". Whitten, J., Bentley, L., Dittman, K. (2004). Systems Analysis and Design Methods. McGraw Hill/Irwin: New York.

Page 10 of 10