scispace - formally typeset
Search or ask a question
DOI

A systemic paradigm for early IT system requirements based on regulation principles

01 Jan 2003-
TL;DR: The Lightswitch approach, described in this thesis, was designed as a tool for IT system designers to create initial requirements taking into account the enterprises needs for stability and change in terms of goals.
Abstract: IT system is a general term for all software based business applications used in enterprises. IT systems support the actions of an enterprise by processing information about the enterprise and its environment and by providing this information to the enterprise and its stakeholders. An enterprise's actions have a direct influence on its ability to succeed in its environment. IT systems, therefore, have a direct influence on the enterprise's long term success. Hence, IT systems are considered to be of strategic importance in most contemporary enterprises. Although enterprises, most of the time, attempt to maintain their identity, forces within them and in their environment push them to change. Enterprise strategy therefore seeks to balance the need to remain the same with the need to change. This balance is maintained by specifying change that the enterprise is capable of sustaining and that the enterprise believes are necessary for its continued success. The design of IT systems should reflect this need for stability and change. The requirements of an IT system are the description of what the IT system will be like and how it will behave. The initial understanding of the requirements is called early requirements. Early requirements define the problems the enterprise is trying to solve and sketch the possible solutions to these problems. An envisioned IT system is often part of these solutions. Enterprise Architecture (EA) and Goal-Directed Requirements Engineering (GDRE) propose methods for defining early requirements by considering the goals of the enterprise and its stakeholders. The concept of goal is used to give structure to the different perspectives on the enterprise defined by its stakeholders and to express the resulting requirements for the IT system. The EA and GDRE literature does not propose a conceptual foundation that gives meaning to the different kinds of goals specified by the EA and GDRE methods as well as how these goals are formed and modified in enterprises. Moreover, EA and GDRE methods are often influenced by Business Process Reengineering (BPR) which is known for specifying radical, often unsustainable change. The resulting early requirements specify goals that could have been changed or that specify too much change for the enterprise. The Lightswitch approach, described in this thesis, was designed as a tool for IT system designers to create initial requirements taking into account the enterprise's needs for stability and change in terms of goals. The Lightswitch approach consists of a conceptualization and a modeling framework. The Lightswitch conceptualization explains the goal-directed behavior of enterprises from the standpoint of the maintenance of success in a changing environment. It is based on General Systems Thinking (GST) and Cybernetics principles. Combined, these theoretical perspectives offer an evolutionary viewpoint describing enterprises as systems that maintain their internal order by regulating their relationships with other systems. GST and Cybernetics offer a set of principles with which to understand this regulation. These principles are used in the Lightswitch conceptualization to explain how enterprises regulate their relationships with their stakeholders in order to remain successful. The Lightswitch conceptualization provides an explanation, in an enterprise context, of the different kinds of goals specified in the EA and GDRE literature. The conceptualization forms the theoretical background of the Lightswitch modeling framework, a goal-directed modeling framework that enables IT system designers to specify early requirements for an IT system based on the enterprise's regulation of its relationships with its stakeholders. The Lightswitch framework complements existing EA and GDRE methods by enabling designers to model both the stability and the changing nature of the relationships of the enterprise with its stakeholders. These models help designers to better understand the enterprise's goals, to propose changes to these goals if deemed necessary, and to specify early requirements for the enterprise's IT systems in the form of high-level goals. This thesis contributes an original conceptualization and method to EA and GDRE. Concretely, the Lightswitch approach consists in reflecting on the conditions that brought the enterprise-under-consideration to be what it is today, to analyze how well it is adapted to its present conditions, and to attempt to foresee some of the challenges it may face in the future. The early requirements for the IT system should reflect these past, present and future perspectives. We present three case studies in which the Lightswitch approach was used to specify the early requirements for an enterprise IT system. Two of the case studies were performed in industrial settings.
Citations
More filters
Proceedings ArticleDOI
29 Aug 2005
TL;DR: A set of principles are proposed that explain the nature of goal-oriented behavior based on regulation mechanisms as defined in general systems thinking and cybernetics and are used to analyze the existing definitions of these different kinds of goals and to propose more precise definitions.
Abstract: Goal is a widely used concept in requirements engineering methods. Several kinds of goals, such as achievement, maintenance and soft goals, have been defined in these methods. These methods also define heuristics for the identification of organizational goals that drive the requirements process. In this paper, we propose a set of principles that explain the nature of goal-oriented behavior. These principles are based on regulation mechanisms as defined in general systems thinking and cybernetics. We use these principles to analyze the existing definitions of these different kinds of goals and to propose more precise definitions. We establish the commonalities and differences between these kinds of goals, and propose extension for goal identification heuristics.

132 citations


Cites background or methods from "A systemic paradigm for early IT sy..."

  • ...In particular, more regulation heuristics can be defined beyond [12, 13]....

    [...]

  • ...Based on the regulation principles and their link to GORE concepts described above we can extend the existing GORE heuristics presented in Section 2 with the following ones (more heuristics can be found in [12] and [13])....

    [...]

  • ...The practical use of Lightswitch was demonstrated in [12, 13]....

    [...]

Journal ArticleDOI
TL;DR: Identifying a minimum set of invariants provides a basis for defining flexible processes and support systems and is illustrated with production business process support (BPS) systems.
Abstract: Enterprise survival is about maintaining an identity that is separate from other enterprises. We define flexibility as the ability to change without losing identity. The identity of an enterprise can be analyzed as a set of norms and beliefs about these norms held by its stakeholders, such as customers, employees, suppliers, and investors. Business processes and their support systems maintain invariants that are the result of compromises between the often conflicting norms and beliefs of these stakeholders. We formalize these invariants as values in a state space. Identifying a minimum set of invariants provides a basis for defining flexible processes and support systems. We illustrate the use of this framework with production business process support (BPS) systems.

68 citations

01 Jan 2005
TL;DR: This paper examines organizational flexibility and business processes from the point of view of the regulation of relationships between stakeholders and pro-poses a set of high-level requirements for business process support systems for the maintenance of business process flexibility.
Abstract: Maintaining flexible business processes is a difficult task since a business process typically satisfies the needs of several stakeholders. In this pa-per we examine organizational flexibility and business processes from the point of view of the regulation of relationships between stakeholders. We then pro-pose a set of high-level requirements for business process support systems for the maintenance of business process flexibility.

65 citations


Cites background or methods from "A systemic paradigm for early IT sy..."

  • ...For the observer, a set of norms define the identity of the system [6]....

    [...]

  • ...To better understand the limits of their flexibility, we use the regulation-based view proposed in [6] and [7]....

    [...]

  • ...From this point of view, a business process can be seen as a norm [6, 8]....

    [...]

Proceedings ArticleDOI
06 Sep 2004
TL;DR: The Lightswitch approach is presented, an approach for defining early requirements for enterprise IT systems, which can model the way an enterprise regulates its relationships with its environment, identify changing conditions within the enterprise and its environment and propose options for changing this regulation.
Abstract: We present the Lightswitch approach, an approach for defining early requirements for enterprise IT systems. Using the approach, engineers can model the way an enterprise regulates its relationships with its environment, identify changing conditions within the enterprise and its environment, and propose options for changing this regulation. The engineers can then define initial IT system goals necessary for the above changes. The use of the approach is shown in the real case of a hospital's sterilization department.

33 citations


Cites background from "A systemic paradigm for early IT sy..."

  • ...In the following list we mention only a few of the heuristics from [6]....

    [...]

Journal ArticleDOI
TL;DR: A theoretical framework based on the concept of homeostasis, the maintenance of identity in a changing world is proposed, which classifies business processes into three levels (strategic, operational, regulative) and analyse the relationships between these three levels.
Abstract: Purpose – The purpose of this paper is to provide a framework for understanding value‐added and abuse prevention activities in business processes.Design/methodology/approach – The paper considers business processes as a regulation mechanism that an organization uses to survive and flourish in its environment. It proposes a theoretical framework based on the concept of homeostasis, the maintenance of identity in a changing world. In this framework the paper classifies business processes into three levels (strategic, operational, regulative) and analyse the relationships between these three levels. Based on this framework, the paper extends the “Use and Misuse Cases” technique to support modelling of value‐added and abuse prevention activities.Findings – The main finding is the importance of considering business processes as regulation mechanisms. Traditionally, business processes are analysed through the goals they are designed to achieve. This paper analyses what the organization aims at maintaining. This...

32 citations


Cites background from "A systemic paradigm for early IT sy..."

  • ...…processes The traditional view of business processes as sets of activities designed to achieve a well-defined goal (Hammer and Champy, 1993) can be enriched by considering businesses as open systems that regulate relationships with their environment (Checkland and Scholes, 1990; Regev, 2003)....

    [...]

References
More filters
Book
01 Jan 1981
TL;DR: The Soft Systems Methodology (SSM) as discussed by the authors is an alternative approach which enables managers of all kinds and at any level to deal with the subtleties and confusions of the situations they face.
Abstract: Whether by design, accident or merely synchronicity, Checkland appears to have developed a habit of writing seminal publications near the start of each decade which establish the basis and framework for systems methodology research for that decade."" Hamish Rennie, Journal of the Operational Research Society, 1992 Thirty years ago Peter Checkland set out to test whether the Systems Engineering (SE) approach, highly successful in technical problems, could be used by managers coping with the unfolding complexities of organizational life. The straightforward transfer of SE to the broader situations of management was not possible, but by insisting on a combination of systems thinking strongly linked to real-world practice Checkland and his collaborators developed an alternative approach - Soft Systems Methodology (SSM) - which enables managers of all kinds and at any level to deal with the subtleties and confusions of the situations they face. This work established the now accepted distinction between hard systems thinking, in which parts of the world are taken to be systems which can be engineered, and soft systems thinking in which the focus is on making sure the process of inquiry into real-world complexity is itself a system for learning. Systems Thinking, Systems Practice (1981) and Soft Systems Methodology in Action (1990) together with an earlier paper Towards a Systems-based Methodology for Real-World Problem Solving (1972) have long been recognized as classics in the field. Now Peter Checkland has looked back over the three decades of SSM development, brought the account of it up to date, and reflected on the whole evolutionary process which has produced a mature SSM. SSM: A 30-Year Retrospective, here included with Systems Thinking, Systems Practice closes a chapter on what is undoubtedly the most significant single research programme on the use of systems ideas in problem solving. Now retired from full-time university work, Peter Checkland continues his research as a Leverhulme Emeritus Fellow. "

7,467 citations

Journal ArticleDOI

6,484 citations


"A systemic paradigm for early IT sy..." refers background in this paper

  • ...For Simon (1996) systems, hierarchies, goals, and complexity all exist in nature....

    [...]

  • ...Simon proposed that managers make decisions with a process he called bounded rationality (Simon 1996)....

    [...]

Book
01 Jan 1999
TL;DR: You may love XP, or you may hate it, but Extreme Programming Explained will force you to take a fresh look at how you develop software.
Abstract: Software development projects can be fun, productive, and even daring. Yet they can consistently deliver value to a business and remain under control.Extreme Programming (XP) was conceived and developed to address the specific needs of software development conducted by small teams in the face of vague and changing requirements. This new lightweight methodology challenges many conventional tenets, including the long-held assumption that the cost of changing a piece of software necessarily rises dramatically over the course of time. XP recognizes that projects have to work to achieve this reduction in cost and exploit the savings once they have been earned.Fundamentals of XP include: Distinguishing between the decisions to be made by business interests and those to be made by project stakeholders. Writing unit tests before programming and keeping all of the tests running at all times. Integrating and testing the whole system--several times a day. Producing all software in pairs, two programmers at one screen. Starting projects with a simple design that constantly evolves to add needed flexibility and remove unneeded complexity. Putting a minimal system into production quickly and growing it in whatever directions prove most valuable.Why is XP so controversial? Some sacred cows don't make the cut in XP: Don't force team members to specialize and become analysts, architects, programmers, testers, and integrators--every XP programmer participates in all of these critical activities every day. Don't conduct complete up-front analysis and design--an XP project starts with a quick analysis of the entire system, and XP programmers continue to make analysis and design decisions throughout development. Develop infrastructure and frameworks as you develop your application, not up-front--delivering business value is the heartbeat that drives XP projects. Don't write and maintain implementation documentation--communication in XP projects occurs face-to-face, or through efficient tests and carefully written code.You may love XP, or you may hate it, but Extreme Programming Explained will force you to take a fresh look at how you develop software. 0201616416B04062001

6,030 citations


"A systemic paradigm for early IT sy..." refers methods in this paper

  • ...Proponents of so called Agile methods such as the Agile Alliance (http://www.agilealliance.org/) now prescribe the specification of just enough requirements for the project to begin; with the requirements being refined and updated as the project evolves (Beck 1999), Cockburn 2000)....

    [...]

Book
01 Jan 1995
TL;DR: In this paper, the authors set aside much of the received wisdom of the last 200 years of industrial management and in its place presented a new set of organizing principles by which managers can rebuild their businesses.
Abstract: "Reengineering the Corporation" sets aside much of the received wisdom of the last 200 years of industrial management and in its place presents a new set of organizing principles by which managers can rebuild their businesses. The book provides numerous examples and in-depth case studies of how leading organizations are achieving significant competitive gains through reengineering: How Ford Motor reduced the size of its North American accounts payable organization by 80% while improving the process; how IBM is leasing subsidiary cut its deal-making process from seven days to four hours; and how Taco Bell used a new set of production and management processes to fuel a six-fold growth in revenue.

5,812 citations

01 Jan 2003
TL;DR: 'Without symbolism the life of man would be like that of the prisoners in the cave of Plato's simile; it could find no access to the "ideal world" which is opened to him from different sides by religion, art, philosophy, science.
Abstract: 'Without symbolism the life of man would be like that of the prisoners in the cave of Plato's simile…confined within the limits of his biological needs and practical interests; it could find no access to the "ideal world" which is opened to him from different sides by religion, art, philosophy, science.' Ernst Cassirer 1 ABSTRACT I begin by outlining some of the positions that have been taken by those who have reflected upon the nature of language. In his early work Wittgenstein asserts that language becomes meaningful when we tacitly adhere to the rules of logic. In his later work he claims that lan- guages become meaningful when they are situated within forms of life. Polanyi describes language as a toolbox for deploying our tacit awareness. A meaning is generated when a point of view attends from a subsidiary to a focal awareness. Languages re-present these meanings. Although all languages rely upon rules, what it is to be a meaning is not reduc- ible to rules. Nor is there a universal grammar. Because it renders abstract reflection possi- ble, language renders minds possible. A mind is not the product of an innate language of thought; it is a consequence of indwelling within a natural language. Indwelling within languages enables us to access new realities. Languages however do not supply us with the boundaries of the world. Not only do we know more than we can say, we can also say more than we know. The ultimate context of our linguistic meanings is not our social practices; it is our embodied awareness of the world. A representationalist account is in accordance with the view that minds are Turing machines. But the symbols processed by a Turing ma- chine derive their meaning from the agents that use them to achieve their purposes. Only if the processing of symbolic representations is related to the tacit context within which they become meaningful, does a semantic engine becomes possible.

4,598 citations


"A systemic paradigm for early IT sy..." refers background in this paper

  • ...Maybe because we are limited in what we can express in our models, be they graphical, formal, or natural language with respect to what we know (Polanyi 1983), our models tend to be somewhat mechanistic....

    [...]