A fundamental challenge for information systems professionals is the development of information systems that are flexible and can respond to changing user needs within an unstable business environment. System flexibility is a problem that has long haunted the profession and it may be argued that traditional approaches to system development result in static systems that have to work in a dynamic world. This is witnessed in both statistics related to the cost and time devoted to software maintenance and the literature devoted to understanding information systems failure. Building on the foundations of object-oriented approaches to development, ‘component-based development’ has been proposed as a software engineering approach that can enable the development of flexible and evolutionary systems. This is primarily a consequence of mixing the flexibility of object-orientation with the encapsulation of earlier modular approaches to software development. From an object perspective, components may be simplistically viewed as collections of related classes that are strongly encapsulated, communicating with the outside world only via interfaces. With significant behavioural characteristics embedded, this allows them to be viewed as independent units of production, acquisition and deployment. Consequently, in Utopian terms, the component-based approach aims at the dynamic composition of information systems from pre-fabricated heterogeneous software components in a ‘plug-and-play’ fashion. Organisations can thus acquire black-box components from different sources at different times and deploy them as they see fit.
From an organisational perspective, this ideal places an emphasis on systems integration as opposed to development. It also has interesting ramifications in ethical terms that relate strongly to the concept of ‘trust’. Components, potentially drawn from a number of diverse sources, will be integrated together and allowed to operate on data that may be sensitive at both the individual and corporate level. The black-box nature of components mandates that the user organisation will understand the component only in terms of what is stated in its interface specification(s) and any additional documentation that is supplied. This means that the organisation integrating components will have to (a) trust that a component does exactly what it says that it does, (b) trust that a component does not inadvertently mishandle the data that it operates with/upon and (c) that a component does not covertly pass data to entities outside the originating organisation’s sphere of control. With the growing role of Web-based communication some of these issues exist already, with point (b) above evidenced in a recent case where it was discovered that users registering Microsoft’s Windows 98 online were inadvertently sending a number that would identify their PCs. Such issues are, however, exacerbated in the component world as, in a dynamically extensible system, it is not necessarily possible to know which components will use what data and when. This feature of component-based development has particular significance for data protection.
This paper considers the above points in the context of the provisions of the recent European Union directive on data protection (95/46/EC) as they are implemented in the new Data Protection Act (1998) in the United Kingdom. The 1998 Act defines the conditions for processing data and has enhanced provisions for data subjects (i.e., individuals who are the subject of personal data). More specifically, data subjects are entitled to (a) a description of the data being processed, (b) a description of the purposes for which it is being processed (c) a description of any potential recipients of their data and, except in limited circumstances, (d) any information as to the source of their data (where available). In addition, where the data is processed automatically, and is likely to form the sole basis for any decision significantly affecting the data subject, then they will also be entitled to know the logic involved in that decision making. Thus, the Act affects component-based developed systems, to the extent that these process personal data.
The discussion for the interpretation of the Act and its implications for business and information systems development are ongoing while the compliance deadline approaches. During this time information systems developers and users need to consider on the one hand the ways in which data protection legislation restricts information systems development and on the other hand the ways in which information systems development practices limit or enable data protection. We believe that our study of data protection in a component-based development environment contributes to this discussion and unveils a complex ethical debate for data controllers (i.e., those who determine the purposes for which and the manner in which any personal data are, or are to be, processed), the supervisory authority that oversees data protection, and information systems developers.