Software Culturalization

---

Cultural Characteristics

The three systems discussed in this chapter are examples of culture-dependent applications. They capture mechanisms that depend on culture and evolve together with other social systems: management, coordination, cooperation, decision-making and problem solving.

We are concerned here with applications which are based on organizational and intra-organizational models, individual problem solving approaches and procedures, group and meeting systems, and systems for knowledge extraction and manipulation. We are also concerned with software agents representing and acting on behalf of individuals and organizations, and systems used for games and simulations. These systems solve problems and make decisions using rules, models and procedures that are rooted in a culture and incorporate its values and symbols. Procedures and algorithms to construct and solve problems are implemented in the software core. If they are culture-dependent, the core is also culture-dependent.

The depth of culture-dependence varies across application domains. A desktop productivity application, a web-based banking facility, and an e-commerce framework all capture different degrees of the culture within which they were created. The culturally dependent functionality in a productivity application, such as a drawing program, may be low because the core goal of the application is independent of culture. Internationalization makes this application more usable and deeper localization may be unnecessary if the core tasks are independent of cultural concerns. In contrast, an e-business framework, web-based customer relationship management and a web-based banking interface are forms of real-world social interaction. In order to be intuitively understandable, these applications must capture a cultural model that describes how they will use motifs, metaphors, information architecture and navigation in order to mimic cultural interaction. The applications for which cultural-dependence must be considered during design are those whose core requirements involve culture-dependent tasks.

The applications for which cultural-dependence must be considered during the design process are those whose core requirements involve culture-dependent tasks and processes. To determine these tasks and processes, we need to study how they are undertaken in the target cultures and compare with their equivalents in the production culture. This is challenging from both research and engineering perspectives; IS researchers and IT developers need to take into account many different perspectives from philosophy, sociology and anthropology. The difficulty in determining what can be generalized across cultures and what needs to be customized to a given culture is one of the reasons why there has been little formal research on the software-culture relationship. The few exceptions include accounting and taxation software whose core functionality depends on localized rules and conventions. In contrast, cultural differences have not been addressed in software that addresses the relationship between people and organizations, for example, customer-relationship management (CRM) and enterprise resource planning (ERP) systems, in which the cultural dependencies are perhaps less direct but just as fundamental.

Culture-Dependent and Culture-Independent Components

The application model partitions a system into presentation, business logic, and data repository tiers (Netscape, 1999; Ben-Natan and Sasson, 2000). The purpose of the presentation tier is to deliver a user interface to the end user of the application. This tier controls the look-and-feel of an application and responds to user events. The business logic tier maintains the application-specific processing and business rules, which define the application processing logic and process flow. It typically makes use of a component technology allowing for the scalability of applications and use of the same components in different applications.

We propose software culturalization, which extends the concept of software internationalization to the business logic of applications. Figure 3 illustrates the localization of an application's business logic in a similar manner as the interface localization presented in Figure 1.

Figure 3: Business Logic Localization.

Software culturalization distinguishes, similarly as software internationalization, culture-dependent components from other components of the core. This is not to say that there are components that are completely independent of any culture; this would contradict the critical theory of technology on which we based the proposed architecture. We note, however, that different cultures share certain values and beliefs, and that there are certain mechanisms used to represent economic processes across many cultures. There are significant differences between, for example, Canadian, French and Polish cultures, and yet the functions used to calculate employees' salaries or the procedures used to manage inventories are the same.

To illustrate the proposed architecture let's consider a shopping cart application used in e-business. The abstract business logic module may contain concepts of a shopping cart, customer and products. Let us assume that shopping decisions in culture A are made by groups of shoppers (e.g., families) but in Culture B by individual customers. Furthermore, products may be either purchased or bartered in A while they can only be purchased in B. This behaviour related to these culture-specific shopping habits and patterns is captured in the libraries.

The construction of an application's business logic, for example, Culture A Business Logic, requires the instantiation of relevant classes from Core Libraries using entities from Culture A Libraries as culture-specific parameters according to the Business Logic design. The Core Libraries provide culture-independent components, for example, member-functions that handle addition/removal of products to/from a shopping cart. The Culture A Libraries contain culture-dependent components, for example, the attributes characterizing shopping groups and attributes of products that shoppers may barter.

Implementation of the cultural aspects in both interface and business logic allows for a significantly deeper software localization. In Figure 4 we illustrate software X developed in culture A and localized in culture B. The resulting software X in B includes—in contrast to the localization depicted in Figure 2—these components of the deep culture of B, which are directly relevant to the business logic.

Figure 4: Culturalization of Software Produced in Culture A.

The business logic is adapted to the particular culture in which the application will be deployed, and as such the mismatch evident in Figure 2 is removed. This removal requires, however, knowledge of the deployment culture and the ability to determine culture dependent models and procedures. It also requires that the modular culture-dependent and culture-independent components be integrated in the application core. The "Core Libraries" are reused in the products, and the individual "Business Logic" strategies are adapted according to the architecture shown in Figure 3. The only part of the software entirely culture-dependent and not reused from culture to culture is the culture-specific libraries (A Libs and B Libs in Figure 4).

Culture and Software Characteristics

Determining which software characteristics are culturally dependent is key. In this chapter, we mentioned that this requires a multidisciplinary perspective. It also requires a reorientation form the focus on the problem in its isolation to the focus on the context in which the problem exists. For example, the problem of purchasing needs to be studied as it occurs in different cultures rather than solely in the production culture. The difficult but critical aspect of the study involves the underlying mechanisms and processes that people and organizations undertake in purchasing. These may involve the issues that are relatively easy to describe such as payment alternatives, but also such hidden issues as trust and independence.

In a typical organization of employees in an enterprise, the structure of an enterprise and the relationship among enterprises differ. Often an organization's use of software for managing and organizing, communicating and collaborating continuously increases in scope and depth. These two phenomena have been widely researched. Study of their juxtaposition is necessary to determine those underlying structures and processes that have to be embedded in software but which differ in different cultures (national as well as organizational).

It has been long recognized that management, communication and collaboration depend on culture and evolve together with other social systems. The current perspective rooted in modern engineering is to ignore the "cultural nuances and differences" as much as possible. The engineering design process isolates the problem from the environment (cultural and other) and concentrates on its modelling, prototyping, testing, debugging, etc. Moriarty (2000) notes that this form of engineering integrates theory and practice outside of the context in which the product is developed and in which it is to function. Following Borgmann (1984), he proposes focal engineering that is concerned with the role of products in supporting "the good, in the sense of human life of harmonious connections and continuities."

The recognition of context in the engineering design process goes beyond the user-product relationship that is of the user interface concern. The consideration includes the user-product-world relationship and the recognition that the product plays many different roles in this relationship including changing the world (Moriarty, 2000). This broader and deeper perspective recognizes that software impacts the way people and organizations function, and requires that the designers take this into account. One obstacle in implementing this perspective may be in the role context plays in different cultures. In low context cultures communications have precise meaning and require little relationship to the broader context in which they occur; words are simply the context or the content of the communication. In high-context cultures communications have often ambiguous meaning open to different interpretations; words and media are part of larger context and need to be valued in accordance to several variables, including the previous relationship, the purpose of the conversation and the non-verbal activity.

Software development in low-context cultures maybe seen more in purely utilitarian terms than in the high-context cultures where it may be seen as an element which affects, and is affected, by a larger context. In the low-context societies the user interface may not need to be related to the users' background, culture and values, but to their abilities which are considered in abstract from their roots (e.g., ability to recognize and interpret meaning of a colour or an icon). The mainstream U. S. culture is, according to Harry (1992, pp. 111–112), "in comparison to that of many other countries, markedly 'low-context' in its reliance on positivistic criteria for truth and in its tendency to exclude and treat as irrelevant the complexities of human perception and personal interaction." (See also, Hall, 1976 and Hofstede, 1997, among others.) If the key market for application is low-context then the main concern of software developers may be software usability and its effectiveness rather than roles it may have in shaping the users culture and modifying their behaviour. This may especially be the case if software is seen purely as a product or a tool which should have well define use and capability. Ambiguity in its use and multiple interpretations are not desired. Development of software for context-rich societies is more difficult but, as we suggest in the next section, may now be feasible.

---