Challenges in Information Systems Engineering
Janis A. Bubenko jr
Kungl Tekniska Högskolan and Stockholm University
Department of Computer and Systems Science (DSV)
Electrum 230, S-164 40, Kista, Sweden
Report No. DSV 98-004
Invited talk at the 3rd Baltic Workshop on Data Bases and Information Systems, 13-17 April, Riga, Latvia.
Information Systems Engineering is …?
I am no longer sure where to set the boundaries of ISE. I am not even sure it is important. What I feel is important are significant issues, critical for the success of developing information systems of benefit for applications are considered during the system development process, under the name of ISE or under any other adequate name. We should be aware that successful development of ISs today requires collaboration between a large number of disciplines as well as specialists and stakeholders. This number is considerably larger than for only ten years ago.
In this talk I will pay attention to a number of practical as well as theoretical issues which I find relevant to focus on in research as well as in practical engineering (or re-engineering) of information systems.
My talk will deal with a number of challenges related to issues like
Company culture
Company culture, as well as developer culture support different ways of doing ISE. The paradigms differ. Things are not the same, for instance, in the Nordic countries and in Greece. There is in my opinion a clear difference in the way problems are perceived, formulated and "solved". In the Nordic countries, for instance, companies typically involve many levels of employees in problem analysis, problem formulation, recognition of opportunities, analysis of strengths and weaknesses, and in formulation of future goals to be set for the IS development work. An important concept in most Nordic companies is "consensus" between multiple levels of employees about recognising the situation and about setting the goals for future. Typically "employee related goals" are given high priority.
In a southern European country, the problems, goals, etc related to an IS, are perhaps more often formulated by a few employees in high managerial positions. Lower level employees, if consulted at all, normally do not express own contradictory opinions - the bosses seem always to be right.
There are advantages and disadvantages with both ways of handling development matters. The Nordic way requires often much more time and work, and if not managed properly it may result in almost endless meetings and debates. The Mediterranean way is normally much faster and less resource consuming. It may lead to development and introduction of new systems in half the time compared to the Nordic way of working.
We believe the Nordic way leads to "better systems, better aligned with the business and its needs". But there is no real proof of this. Even the contrary may be true. It could, for instance, be argued that one good chief architect will arrive at a better design than five or ten architects collaborating and trying to reach consensus.
One thing is probably true: following the Nordic approach: the developed information system will have a higher degree of acceptance and understanding in the organisation, compared to more authoritative ways of working.
What is really the problem here? – It means that a method developed and used in country X will not necessarily be understood, appreciated and applied in another country Y.
What is our challenge here? We need research that investigates these matters and that provides us more knowledge of how things are in different cultures. The same approach or method is evidently not applicable in different situations. This is particularly important considering the expansion of EU.
Ill-structured problems
The nature of problems being addressed by IS engineers has during the years changed. Typical problems of the fifties and sixties addressed primarily systems for order management, invoicing, stock control, distribution, and other bounded and relatively well defined areas. Current information systems have extended these boundaries. Problems now addressed are much more "wicked", such as systems for improving the competitive edge of a company, systems for improving organisational learning, systems for human resource management, etc. The definitions of these problems are not clear, and their scope is more or less arbitrary. The benefits of these systems cannot be easily calculated or predicted.
Some typical traits of these problems are
These new types of problems need a different approach than the old ones. This is the challenge. We need methods, tools and a new way of working that support "taming" them. This also requires a change of the company culture towards a more participative way of working.
Business engineering and business modelling are new methods and techniques that seem promising in this area but there is much more to research and experiment with before we arrive at a reasonably workable methodology. The "situation dependency" comes in here as well.
Justification
A consequence of the new types of ill-structured, wicked problems is that the benefits of solving them are not easy to calculate and predict. It is no longer the question of calculating the savings of reducing the staff of some company functions or reducing the inventory to be maintained. It is now more relevant to assess the value of improved communication with customers as well as vendors in order to stay in business, or to improve the market share of the company. In other cases it is the question of assessing the value of improving the organisational competency in order to meet future competition. In yet another case it may be the need to analyse customer behaviour and performance in order to adapt the products of the company to emerging markets. Which are the benefits of these new types of systems?
An important issue here is to be able to achieve attention and support from the top management for these types of issues. It is no longer enough to obtain the management's blessing for making expenditures in this area. What we need is the serious participation of management in discussions of how to strategically use IT in order to improve the competitive advantage of the company.
The challenge is find means how to open up the management for that type of involvement and understanding. The Information System issue is no longer a question of only the IT department or IT consultants.
People and development work:
The new types of problems require a different attitude in IS development and a different approach to developing systems. The distinction between developers and users is no longer sharp. Users are much more active in the early phases of development, but are also increasingly active in working on issues closer to implementation, for instance, HCI-issues, usability and that like.
A challenge here is to develop good schemes for collaborative work, preferably within the framework of CSCW. We talk and publish a lot about CSCW but there is little experience and knowledge of how to use the technique for systems development, distributed, distance work etc. Much more can be done here I feel.
Improved user participation also requires additional training of the "users". The problem here is that companies normally do not realise that education of users of advanced IT systems is not a matter of a couple of half day courses. Much more time is needed for training in methodology as well as in different techniques and tools. There are, however, exceptions to this company attitude. The Sweden Post, for instance sends each year 30 of their skilled employees to take full time part in a one year academic continuing education in IT and adaptation of IT and business systems.
Perhaps the biggest problem is to get companies to understand that participation requires not only added skills of stakeholders, but also considerable stakeholder time. Stakeholders need to understand relatively detailed designs, for instance, detailed business rules to be embedded in the system. The level of detail and precision required for good quality system designs is typically much higher than companies understand and are willing to pay for (through participation and by giving strategically knowledgeable people time to participate).
New skills
There is a need for a more differentiated set of skills in the process of developing information systems. New types of skills are needed. Systems analysts and programmers is no longer a sufficient partitioning of "workers" in a development project. It is a challenge to identify these skills as well as to provide them adequate training.
Some recognised types, in addition to business specialists and IT-specialists of various kinds in participative business modelling are:
Development of an Information System is no longer only a question of the IT department or of IT consultants. It is an issue that involves a broad group of stakeholders and that needs adequate knowledge acquisition as well as presentation facilities for non-IT specialists. In Sweden, for instance, ideas for drastically new types of schools have emerged, where collaboration of IT specialists and other disciplines such as film production, film directing, music, fine arts, the humanities, etc. is envisaged. The challenge, of course, is how to make something concrete out of this mix of disciplines, where the concept of "research" or of a "scientific result" is interpreted differently.
Methods and techniques
Most, if not all system development methods do hardly address the issue that the kind of problems we most often are tackling are "wicked". Most method research deals with development (or re-development) of formal description techniques with a high expressive power for describing things which can be formally described.
Problems that methods & techniques normally do not address are, e.g.
Development of formal description techniques is, of course OK, but it does not help to solve many of the problems in business and industry.
The challenge here can be described as "how to effectively deal with informality".
Informality
Many IT development projects deal today with engineering or re-engineering of business processes and with providing adequate IT-support for the processes. The development process can, in its initial stages, often be described as
Very little of this can be described in purely formal terms. Furthermore, the use of advanced formalism will hinder the understanding and creativity of the participating stakeholders. Regarding the first two bullets above, we came to the conclusion, working on a truly "wicked" case that "All tricks should be permitted as long as you get what you need from the stakeholders". Tricks may include things such as: use "pop-graphs", "write future scenario stories", "identify important directions for your company", etc. These kinds of descriptions are not normally included in IT methodologies.
On the other hand, in order to manage the process effectively, we need well documented and structured ways of representing the concepts above, such as goals, problems, and weaknesses, etc. of an organisation and to reason about what they are and how they are related.
Challenge: improve the degree of "formality" of the type of descriptions (models) mentioned above in order to improve the possibility for computer support in model analysis and in assistance to stakeholders, but without introducing "straight-jackets" in the methodology.
Tools and Media
Tool and method issues are, of course, very much interdependent. A bad method will not become much better by the use of tools. I also have the feeling that our current methods do not fully recognise nor use the possibilities that new multimedia oriented computers offer. Another largely unused facility is the Internet or the Intranet.
One tool issue is, in my opinion, very much related with the limited size and possibilities of the PC based computer screens. PC screens are not suitable for participative group work. The directions we should follow is to develop design-studios using large screens, back-projection, internet techniques, and multimedia technology. For instance, in documenting requirements or in describing business processes it would be advantageous not only to use graphs and text but also sound, pictures, video slips as parts of presenting existing or future situations.
But we also need to improve technologies how stakeholders can more actively participate in design and walk-through sessions. For instance, the use of XEROX live-boards is such a possibility, where stakeholders can actively and individually develop or modify designs on large screens.
Challenge: What we need is to develop techniques how to use new computer and media technology and related facilities in development projects.
Components, Reuse & Patterns
The "pattern movement" emerged, I believe, first in the field of architecture and has then via Object Oriented techniques entered the field of IS. Right now I am not sure what to think about the claims made by this movement. The basic idea is that "patterns" of different kinds, perhaps made more generic, can be catalogued in libraries and then reused when the need for particular solutions arises and if found.
Some more modest proponents of patterns suggest that patterns can possibly be useful in order to give hints about how similar situations have been represented or solved in other cases, and in that way stimulate thinking and give ideas of particular designs. Other, more optimistic proponents believe patterns and the process of using patterns can be formalised to the extent that, staring out with a description of a current situation or a goal to be reached, the "knowledge base of patterns" can lead you to a solution of the design problem.
I believe the optimists may achieve some success in well defined problem areas, for instance working in a similar way we did for many years ago by defining sub-routines for well defined tasks. I am less optimistic about a strict use of patterns for the kind of problems we define as ill-defined of wicked. On the other hand, I believe it is a challenge to investigate how to define and how to use patterns in the wicked fields of business process engineering, strategic planning, etc. For instance, it may be of interest for a company to investigate possible problem-goal patterns within a particular business domain which are experienced by others, before setting up own goals. In the same way, it may be of interest for a company to investigate how other, experienced companies have defined their conceptual structures for products, services, customers, etc. Use of patterns should not imply the need to accept everything but rather to get ideas and concrete examples.
Challenges related to patterns are: how to make good pattern descriptions and how to find patterns of relevance to your problem. These challenges are the same as for the re-use movement. Another problem here is how to prove that a pattern, or a set of patterns, is (partially) indeed a solution to your problem.
Emerging disciplines
In the area of IT, new disciplines are popping up all the time. Examples: CSCW, HCI, Interoperable IS, Web-based Information Systems, Intelligent Agents, Virtual Reality, Multimedia, and many others. This reflects that the "old" ISE community no longer can cope with the multitude of techniques, approaches, requirements, opportunities, etc. New disciplines are spun-off either from the ISE field of from scratch facing the needs of the society.
This is fine, but there is also a danger. The danger is that many of these "new" disciplines more or less lack the "engineering tradition" of systematic development and documentation, including requirements acquisition and specification, formal description and analysis, strict and timely documentation, software process measurement and management, etc. In many cases systems development has become close to "hacking". In many cases Information Systems Engineering is not even a recognised concept.
This, however, may bring the new discipline into the same situation as AI experienced during the eighties. There were many claims and high expectations at that time of what AI could accomplish. Most research in AI was, however, done on toy problems. Few of these solutions could later be adapted to problems of realistic complexity.
If managed properly, ISE could perhaps become a discipline that uses and integrates a multitude of other disciplines and skills within a systematic framework.
This brings us to the issue of relevance of research.
Research and relevance
One of the challenges of ISE research, I feel, is to do research that (more quickly) leads to solution of practical, real-life problems. This is what I denote relevant research. You may object to this, but ISE is an applied discipline and it should focus on engineering.
IS research should identify and tackle the hard problems of the IS community and not try to escape them by focusing on small, well-defined and formally manageable subsets of those problems.
This is easy to say but difficult to implement considering our current academic culture and beliefs of many of what "engineering" or "science" is Also, our current reward systems, may it be academic positions or acceptance of papers for a journal or a conference, often does not promote relevance in this sense.
How can achieve a change in this situation? Well, the recipe is quite old, if I remember. We need to establish the same collaboration between ISE departments at universities and business and industry as it is in other, well established disciplines, like electrical engineering or civil engineering. A newly graduated engineer in these disciplines, upon graduation, moves to a working environment, where his colleagues work with the same methods and talk the same language.
The way it is in ISE is, as you know, different. How many of the things we learned about IT at the university are understood and being used by our banks, insurance companies, or government organisations? Not many.
What can we do about it? I have worked with this issue for my whole professional life - the only thing I can say - it will take time. Right now there are no signs, considering the fast development pace, that say that we eventually may achieve a more stable situation and a better alignment of business and industry to academic know-how and products. To achieve such an alignment "would be nice" but I am not sure it will solve the real problems.
One thing is, however, clear to me: we need a much more intense and constructive collaboration between academia and industry. This is true for the whole industrial world, but it may be particularly important that Baltic business and industry takes advantage of the knowledge and skills that are offered at their universities.
Identity Crisis?
Is there a crisis regarding the identity of ISE? Or is the discussion of an identity crisis mainly apparent in the Western countries with a longer tradition in the field?
In a way there has been a continuous identity crisis since the sixties. This seems true at least for people who wish to have a stable definition and subdivision of the area. But, is "identity crisis" not a healthy sign of growth and evolution? People working in this area today are not only the ones who are formally educated as IS engineers at computer science and related departments of our universities. There are many more players in the area ranging from economists, media people, people from arts and humanities, behavioural scientists and others.
You cannot design systems with "Participative design" only without considering the need for precise, formal descriptions at the end. Likewise, you cannot design systems only by being an expert in formal description techniques. Capturing organisational knowledge is not done in that way at the beginning of a development process.
I hope the "crisis" will continue and force us to re-examine what ISE should be, and how we can extend our methods and techniques in order to better tackle the kinds of problems that emerge in the "information society".
In summary
In summary, I believe my main message is that in order to survive, the traditional field of ISE must realise that people and collaboration are the key issues; collaboration with other disciplines of computer science as well as disciplines we hitherto have not even thought of relevant in the process of developing information systems. We need also to develop new categories of "workers" and skills in this field. Collaboration with our stakeholders is another important issue; we should improve in this aspect as well. Our stakeholders know their business better than we do.
We also need to realise that the kind of problems we are currently tackling in the IS field are increasingly wicked and ill-structured. Also this needs more collaborative and people-oriented approaches to knowledge acquisition and to IS design.