Why nit-picky definitions of service don’t matter for systems in organizations

Fri, 19 Sep 2008 12:56:19 -0700

Over-selling and under-delivering by downplaying non-technical issues

Fri, 25 Jul 2008 16:40:58 -0700

I think there is a fundamental flaw in the way many of us think about systems and about systems analysis. The fundamental flaw is that we start with the assumption that systems are technologies and that the goal of systems analysis is to produce or modify a technical artifact that someone will use, hence the terminology of "use case,""users," "user participation," etc.

The real business problem is not to produce technical artifacts. The real problem is to improve specific work systems or to create infrastructures that may support the organization in the future.

Contrary to the terminology of the IS field, people who perform the work in work systems should be thought of first as work system participants, not as users of technology.

Another fundamental flaw is that the IS field sometimes confuses analysis with documentation of technical artifacts. Use cases, flow charts, data flow diagrams, ERDs, UML, etc. are about documentation of technical artifacts, which is at maximum just one part of analysis. Analysis is about defining a situation (system), identifying problems, issues, and challenges, and then obtaining and using information that leads to a recommendation about how to improve a work system. Parts of the recommendation should focus on creating or improving technical artifacts. Other parts should focus on changing procedures, training people, changing incentives, breaking political barriers, attaining better coordination, etc. Things such as these are very important even though they may not involve existing or proposed technical artifacts.

Translating Lightweight Analysis into Heavyweight Analysis

Wed, 16 Jul 2008 11:55:00 -0700

Heavyweight systems analysis approaches such as the use of Unified Modeling Language (UML) are inappropriate for business professionals who nonetheless need to participate actively in systems analysis and design processes to ensure that the system requirements reflect their needs.

I am currently working with Xin Tan and Keng Siau to develop semi-formal methods for translating from the type of analysis that business professionals can perform (with or without the help of IT professionals) into the formal documentation that is needed for efficient software development.

Our approach uses “service responsibility tables,” (SRTs) which are based on the assumption that services are usually co-produced by providers and customers. More or less like a two-column swimlane diagram, the first two columns in an SRT identify the (active or passive) responsibilities of both service providers and service consumers throughout a service process. It is easy to extend a two-column SRT into a three-column SRT that adds a new column for any of a number of topics that might be important for analyzing a particular system. As explained in our AMCIS 2008 paper, we have developed preliminary guidelines for converting from two particular types of SRTs into use cases and class diagrams in UML (Unified Modeling Language). We are focusing on guidelines, rather than formal rules, because we assume that IT professionals will perform the translation.

We plan to take the following steps to identify and verify a comprehensive set of heuristics for transforming SRTs to UML diagrams:

• We will identify worked out UML examples in textbooks or other sources. These will be examples that are more or less completely worked out for a particular problem domain and include most of the UML diagrams, as opposed to individual diagrams that illustrate specific points about UML per se.
• For each fully worked out UML example, we will create a set of SRTs that captures as much information as possible from the UML diagrams. In a way, this is a “reverse-engineering” approach.
• For each fully worked out example, we will examine the corresponding SRTs and propose heuristic guidelines for converting these SRTs to the UML diagrams.
• We will review Table 2 to identify typically important topics that are not addressed or captured in UML.
• We will test our heuristics in classroom exercises involving systems analysis and design students. The students will be divided into two groups. One group will attempt to produce UML diagrams directly from descriptions of business situations. The other group will use SRTs as lightweight analysis and will then use the guidelines to convert those SRTs to UML diagrams.
• We will compare the results to determine whether the step of producing the SRTs was useful for the students.
• We will apply the results to extend our ideas about using SRT-based analysis as a step towards creating UML diagrams.
For further explanation, see our paper for AMCIS 2008, Linking Lightweight and Heavyweight Systems Analysis by Converting Service Responsibility Tables into UML Diagrams.

First Entry - Initial topics for this blog

Tue, 15 Jul 2008 12:51:00 -0700

Welcome to my blog. Below are some of the topics I plan to cover, although not necessarily in the same order. Please send your comments about blog entries and your suggestions for future topics.

.... Translating from lightweight analysis (useful for business professionals) to heavyweight analysis (rigorous enough for creating software)

... Is it possible to incorporate more of a service mindset into systems analysis and design?

... Shouldn’t business professionals have systems analysis methods that are directly related to their needs?

... If UML is such a great standard, why are most of the diagrams used so infrequently?

... If Six Sigma is so great, why hasn’t it solved the world’s system problems?

... If the work system approach is so great, why hasn’t it solved the world’s system problems?

... What is “the system” when ERP, CRM, and other software is being discussed?

... Does the definition of service matter?

... Is the commonly discussed SDLC (system development life cycle) a fundamentally flawed model for IT-reliant systems in organizations?

... What might customer-centric systems analysis look like?