We briefly describe the design of a course on “Systems Analysis and Process Innovation”, focusing especially on its project assignments. Students are introduced to process modeling and data modeling, followed by i* and Value Network modeling. In their project assignments, students apply these modeling techniques to real organizational settings to analyze an as-is situation and to explore to-be alternatives. A distinctive feature in the design of the project assignments is that student teams split into 2 sub-teams in which each sub-team uses a different modeling technique to analyze the same domain setting. After each sub-team has separately completed its own work, the two sub-teams then compare their results for the domain problem setting, and more importantly, contrast the strengths and limitations of the two modeling approaches based on their project experience.
In learning a modeling language, it is easy to become preoccupied with language
syntax and semantics while losing sight of the larger purpose of the modeling activity.
One way for learners to maintain some intellectual distance from any particular
language is to recognize that there can be other languages that could potentially achieve
comparable objectives, each with its own strengths and weaknesses. For the past few
years, in a course on “Systems Analysis and Process Innovation” [
In this short paper, we describe the structure of the course and the design of the
assignments, including the final assignment in which i* and VNA are used. The “studio
presentation” component, which encourages peer-facilitated learning, is also
described. More detailed lessons from recent offerings of the course are described in a
companion paper [
The Master of Information program at the University of Toronto, Faculty of Information (also known as the iSchool) is a professional Master’s program aimed at educating students in a variety of information fields. Areas of concentration include Information Systems and Design (ISD), Knowledge Media Design (emphasizing user experience), Knowledge Management and Information Management (emphasizing the management of information content in organizational context), Critical Information Policy Studies, and others. Students are encouraged to take courses across concentrations, and can specialize in up to two concentrations.
“Systems Analysis and Process Innovation” is a required course for the ISD concentration, with a significant number of students from other concentrations and Faculties. A good proportion of students have professional work experience, mostly not in technology areas. A small number have an undergraduate degree in computer science or information systems. As the course is recommended to be taken during the first term in the program, it is for many students their first substantive introduction to the practice of information systems analysis.
The course introduces systems analysis concepts along two complementary threads. One thread highlights the varying degrees of change that can result from a systems analysis intervention – from “automation” (no significant change to the business process), to “innovation” (process redesign), to “transformation” (reconfiguring stakeholder relationships, even transforming the business model). The business process is introduced as a crucial abstraction to move away from solution-oriented, technology-centered thinking.
The second thread emphasizes the need for different kinds of abstractions to help characterize the domain situation, so as to be able to envision alternate “to-be” configurations without prematurely narrowing technology implementation options. Along this second thread, the course progresses from process modeling (BPMN, DFD, UML Activity Diagrams) to data modeling (ERD, UML Class Diagrams), then to approaches offering a broader view of organizational contexts, namely i* and Value Network Analysis (VNA). i* and VNA are offered as two relatively new techniques that can potentially stimulate and trigger thinking towards the more radical, transformative kinds of change. Throughout the course, where models are used, their analytical powers and limitations are emphasized, so that they are not seen as merely descriptive.
The two threads complement and reinforce each other, progressing from small localized change to more fundamental transformations, correspondingly learning about models that increasingly challenge the status quo and uncover their hidden assumptions. The course work assignments follow the same parallel progression.
Value Network Analysis [
Both i* and VNA can be said to be offering higher-level abstractions than traditional information systems models such as process models. Given a particular (re-) arrangement of strategic interests (aided by i* analysis) or value exchanges (aided by VNA), one can potentially implement the new configuration of relationships in multiple ways at the level of processes and activity flows. From the viewpoint of information systems requirements, both techniques are addressing “early-stage” requirements analysis.
Yet, there are significant differences between the two for a contrasting learning experience. For relationships, VNA distinguishes between tangible and intangible value flows, whereas i* distinguishes among several types of intentional dependencies. i* makes explicit the goals of actors, and how they are achieved (in the Strategic Rationale model). i* prompts for consideration of alternate ways for achieving goals, represented through means-ends links. For more detailed analysis, VNA makes use of tables for analyzing impact of incoming flows and value creation of outgoing flows. i* continues to leverage the graph structure for detailed analysis so that impacts can be propagated across the network of links within and across actors. With explicit modeling of goals, which can be conflicting, i* can more readily deal with competing interests as well as malicious actors.
Overall, VNA offers an appealing and intuitive visual map of relationships among actors in a business context, and is readily accessible to the casual reader. The graphical network part of VNA has an initial visual resemblance to i* SD models so can serve as a gentle introduction to the mapping and analyzing of relationships among actors beyond workflow or process type models. In the lecture sequence, VNA is introduced before i*, as it has fewer concepts and simpler analysis methods. 4
To better prepare students for professional practice, all the assignments involve working with real-life cases. In the first assignment, students work individually to obtain a study site, describe the problems it faces, and briefly outline opportunities for using information systems. They identify a business process as a candidate for further analysis. The as-is process is modeled using BPMN and is briefly described.
Process modeling assignment – DFD alongside BPMN. In the second assignment, teams of students (typically of size 4) work together to explore to-be alternatives for one organizational setting. The team selects the setting from among those examined by individual team members in their first assignment, based on their judgments about suitability for detailed analysis as well as pragmatic criteria such as accessibility for site visits and availability of key informers during the study period. Students must comply with research ethics guidelines governing the course work project.
From a modeling viewpoint, students get to experience process modeling in some depth by applying it to an unfamiliar real-life problem. To further enrich the experience, the team is required to use two different process modeling techniques.
After an initial round of elicitation to obtain an understanding of the domain setting, the team work assignment is conducted in two stages. During the first stage, the team splits into two sub-teams of two members each. One sub-team uses Data Flow Diagrams, while the other uses BPMN or UML Activity Diagrams. Each sub-team, working independently, generates several to-be alternatives based on its analysis using its respective process modeling technique. In the report, they only need to detail two of these to-be alternatives, one involving minimal change to the business process (“automation”), the other involving a significant process redesign (“innovation”). They also provide a data model (ERD or UML Class Diagram).
In the second stage, the two sub-teams come together to exchange experiences. They compare their models and the to-be alternatives that are generated, which in most cases, are different. The two sub-teams are therefore able to recognize the different focus or emphasis of the two chosen modeling techniques, and how they led to different results.
The final assignment – i* modeling alongside VNA. In the third and final assignment, a similar split-team approach is used, with two to three members in each subteam. One sub-team uses i* modeling, while the other uses Value Network Analysis. However, to coordinate the more challenging project and to ensure higher quality and better consistency of domain scope and content, an additional member of the overall team acts in the role of “Problem Owner”. The Problem Owner is typically the member who is more knowledgeable about the problem domain, or has more ready access to the study site. The team is not expected to further interact with study site stakeholders for this final assignment.
The objective of Assignment 3 is again to explore potential organizational changes that make innovative uses of IT systems to respond to problems and opportunities. However, the modeling techniques prompt the student analysts to examine value exchanges (in VNA) or to uncover underlying motivations and intents of actors (in i*), thus leading to deeper understanding and potentially more fundamental or transformational changes, which often involve reconfiguration of relationships among actors. As in Assignment 2, the two sub-teams first work independently to come up with to-be alternatives, and then compare notes to gain insights about the two techniques.
In the final report, aside from the detailed analysis results of each of the two subteams, there is a section that analyzes the commonalities and differences in findings obtained by the two sub-teams using their respective techniques, followed by another section that generalizes this comparison to highlight the strengths and limitations of the two techniques. Finally, the Problem Owner offers an assessment of what the subteams were able to accomplish, or not accomplish, using the two techniques, simulating a real-world problem owner or client.
Studio presentation. In the weeks preceding the final presentation, the class sessions include a segment where the class is split into break-out groups in several smaller rooms. Student teams take turns to present their work-in-progress in an informal setting to their peers. The purpose is to provide an opportunity to share experiences and ideas across teams, regarding modeling as well as interactions with study sites. The instructor and teaching assistants circulate among the groups to ensure smooth proceedings, but encourage student interactions and provides only occasional input or responses. The studio presentations are not graded so as to promote an informal atmosphere for open discussion and constructive criticisms among teams. Each break-out group has two volunteer note-takers as well as a facilitator. After the breakout, the class reconvenes. The note-takers bring up highlights from the studio discussions. The instructor provides answers to questions arising from the studios.
Discussions in class and at studio presentations are further supplemented by asynchronous discussion threads on an online discussion forum.
Final presentation. All the teams present highlights of their findings to the entire class at the final 3-hour class session. Students thus get to witness the use of the modeling techniques as applied to very diverse settings, often ranging from start-ups to large enterprises, and domains covering business, government, healthcare, education, and non-profits. The final report is due two days after the final presentation, so that students can benefit from insights arising from the final presentation.
Student reflections. As mentioned, at the end of Assignment 3 students compare the two modeling languages and comment on their respective strengths and weaknesses. To offer a glimpse of students’ perspectives on VNA and i*, a general review was performed over the reflections provided in 16 student group assignments in the 2014 Fall term. The students were generally appreciative of the different nature of the questions that the modeling languages allowed them to ask and answer compared to the process- and data-based modeling frameworks they had used in earlier assignments. Comparing the experiences of sub-teams within a student group revealed that working with VNA was often perceived to be simpler than working with i*. They faced issues of i* model complexity and iterative domain modeling. The notations for VNA were seen to be simpler and easier to visually comprehend whereas the i* notations required more effort.
Some students observed that i* requires a greater depth of knowledge of the domain, as compared to VNA, so as to be able to model the domain to a level where it would sufficiently enable meaningful analysis. Some students found that the detail and depth of information depicted in i* model diagrams allowed them to better find transformative scenarios that would help achieve higher-level organization goals, while on the other hand, VNA diagrams were perceived to be more helpful in optimizing and improving the as-is situations. 5
As an introductory level course on information systems, many students find the syllabus and course work intense and demanding. The course progresses through a number of conceptual and modeling paradigms in the short 12-week period. By adopting a project assignment design in which sub-teams work separately using different techniques then compare and integrate experiences, students are exposed to a wide range of techniques as well as the opportunity for critical reflection.
The approach is not without drawbacks. Due to sub-team specialization, students get more hands-on practice in some modeling techniques than in others. This is despite instructions stipulating that all members of a team develop competency in both modeling techniques in order to fully contribute to the overall team effort. The twostage (split-team then whole-team) format is quite demanding for team logistics. For teams with good group dynamics, this can have the side benefit of being a demanding exercise in project management and time management. As a reminder to contribute fully and equitably to team work, students are required to complete a peer assessment form to describe the contribution of each team member at the end of the course.
As an alternative pedagogical design, the project assignments could focus on a single modeling technique rather than two contrasting ones, giving students time for more in-depth analysis. Currently, even though analysis using the models is emphasized (modeling and analysis are equally weighted for grading), the submitted work tend to be weak on the analysis. However, focusing on a single technique would inhibit student’s understanding of the purpose of using i* and other modeling techniques. Students are encouraged to articulate the benefits and limits of each modeling technique, thus helping them reflect on the types of insights that can be gained by using i* and other approaches. Another alternative for projects assignments would be to base them on historical or hypothetical rather than real world cases; this might make the split-team projects more manageable. However, the learning experience of dealing with real stakeholders facing actual challenges is invaluable. 6