Richard J. Welke

Traditional, iterative, and component-based development: A social analysis of software development paradigms

Information systems have always been developed through social processes, wherein actors playing a variety of specialized roles interact to produce new business applications of information technology. As systems development practices continue to evolve, an ongoing assessment of their social implications is required. This paper develops a framework for understanding the potential social implications of an emerging, component-based development paradigm. Like two alternative paradigms for systems development, the traditional life-cycle and the iterative-incremental paradigms, the new component-based paradigm requires that certain generic roles be performed to build a desired application. For each paradigm, we identify the actors who play different roles, specify the nature of their interdependence, and indicate the requirements for managing conflicts constructively. The framework may guide research into the social dynamics of system development and serve as a tentative guide to the management of information systems development.

Thinking Tri-laterally About Business Processes, Services and Business Models: An Innovation Perspective

We propose a new, integrated “way of thinking” about processes, services and business models. The starting point of this paper is that “getting things done” is the set of services the organization employs. These services are often broken, ineffective and/or misaligned with client/users needs. Any attempt to pre-emptively or reactively respond to market change or internal transformations must invariably rely on some of these (broken) services while, at the same time creating new ones that, in turn, make use of pre-existing services as building blocks. It is argued that services (both internal- and external-facing) are two things: a business process (the “how” of a service), and a mini-business in its own right (the “why” of the service). Each service has clients (the “who”) that, through choice or mandate, solve some, or all, of a problem they have. In short, a service (and its underlying process) represents a “value proposition” to the service consumer (client) that enables them to “get their job done.” A service is, in effect, a mini-business or “business within a business” and therefore is implicitly governed by a business model of the process/service owner, the “CEO” of that business. Adopting this perspective affords a fresh way to view “process” innovation. It can be top-down by considering its business model. Or middle-out, where a specific service for an internal or external client is examined for innovation potential. Or bottom up, where the business process that delivers the service is modified and, in so doing, alters the characteristics of the service being delivered to the client.

Using Problems to Learn Service-Oriented Computing

Service-oriented computing and the ensuing science of services represent significant challenges to academia. As we come to grips with its many implications, we are slowly beginning to realize the challenges of introducing service-orientation in research. The change also requires a rethinking of strategies used for educating computing professionals. Service-orientation questions the traditional vision of the IT professional as a toolsmith. Instead, it requires shifting the role of the IT professional to that of a participant in a multidisciplinary team of diverse professionals. We describe one specific strategy that is a core part of an ongoing experiment to support such pedagogical practices, and reflect on its usefulness and limitations.