I would like to clarify from the beginning that I am going to do my presentation in what can be called "EU Common English", which is neither the UK English, nor the USA English.

It is important to state this point, I think, because, as you will see, I will be talking about "Information Systems", using this term with the special meaning that it has in countries like Portugal, Spain, France or Italy where a word like "informatics" ("informatique" in French) does exist. When, in any English paper we read about "Information Systems", only by the context can one understand if the author in talking about the I/S Technological System, the I/S Department or about what is sometimes called the "Organizational Information System" (sometimes also called the "Information Business" within a company).

When authors like the French Le Moigne or the Spanish Felipe Gómez-Pallete talk about the "Système d’ Information" or the "Sistema de Información", they are talking - as I will be - in a much broader sense; one that incorporates business processes and business organization and their use of information and data, whether it is, or not, in any Computer System. For the French speaking participants let me clarify that I am talking about "Les Systèmes d’ Information" and not about "Les Systèmes Informatiques". And in this context it is important to state that Le Moigne uses the concept of "Organizational Information System", and Felipe Gomez-Pallete uses the concept of the "Enterprise as an Information System".

As I will talk about the Visual Age and the associated paradigm shifts it is also important to begin with the clarification of the terms used. What is the "Visual Age" we all know: and we also know that it means now two different things: one is the "Age of Visual" (GUI, Guided Visual Programming, Multimedia, etc...) and the other is an IBM visual object oriented software development product. My use of the expression "Visual Age" incorporates those two meanings. I am in fact taking some benefit from the confusion of those two meanings created by IBM.

But the second term that needs to be clarified is the one that relates to the word "paradigm" and the expression "paradigm shifts".

WHAT IS A "PARADIGM SHIFT"?

As you probably know the word "paradigm" is the main concept of a book written by Thomas Kuhn, an American Physicist and Science Historian, in 1962, entitled "The Structure of Scientific Revolutions".

The discussion of the concept of paradigm is very extensive in the scientific, philosophical and epistemological papers. But for our purposes a paradigm can be defined as "an overall view of the domain (studied by a certain science), that is generally accepted by the scientific community and determines what are the problems that can be seen and the theories and the practices that must be used".

The Swiss Biologist and Psychologist, Piaget, stated more or less the same saying that "les données ne sont pas données, dépendent des théories et des interprétations qui nous permettent - ou ne nous permettent pas - de les voir" (Data is not given to us - it depends on the theory that allows us to see it).

From Khun’s book we can also understand:

- the importance of analysing history to understand reality and specially the reality that our theories or practices are not able to fully explain or exploit;

- the difference between "normal science" (small improvements, sometimes technology driven) and the periods when a scientific revolution incorporating a substantial paradigm shift is needed;

- the fact that a crisis in the until then dominant paradigm is needed before such a revolution can take place.

You can very well remember some well know paradigm shifts in science:

- Darwin in Biology

- Lavoisier in Chemistry (against Priestley)

- Newton first followed by Einstein later (and twice, by the way) in Physics

- Pasteur in Medicine

- etc...

Khun quotes the French Scientist Pierre Juliot Curie for a statement that he made saying more or less the following: "you may think that the new scientific theories gain acceptance because the followers of the old ones let themselves be convinced of the correctness of the new ideas. But that is not true: in fact they normally never get convinced; but eventually they will all become dead. And the new scientists are all educated in the new concepts".

This quotation is not to frighten you. But I would like you to keep it in mind during the rest of my presentation.

All of us would easily agree that the 2 major changes stated in the exhibit have not been easy (specially for the professionals that were specialized in the techniques that have been suppressed or changed by them) and that they have meant a completely new way of seeing both the I/S and the Business worlds.

I was an IBM System Engineer when the second of those paradigm shifts took place. In fact, I was the co-ordinator of the Structured Methodologies in Portugal, and I created and taught the courses on Improved (Design) and Programming Techniques that I gave to more than 2000 analysts and programmers. I have also been a consultant in projects for changing from Assembler to (Structured) COBOL and for the introduction of Structured Methodologies.

From that experience I have learnt that it was not an easy change. A lot of analysts and programmers couldn’t change at all and a lot of others continued to use flowcharts as the basic analysis tool and a "spaghetti Assembler like COBOL" as the programming tool.

Teaching and acting as a consultant during those changes was a very interesting experience indeed. I have learnt how to help people to stop thinking spaghetti and begin thinking modular and structured.

This experience is now proving to be of great importance when we begin to teach and help people to stop thinking "data oriented" or "process oriented" (in fact, in many cases, "procedure oriented") and begin to think truly "object oriented". This is proving not to be a trivial change and a lot of "data oriented" thinking and methodologies are being used as if they were (but in fact they are not) object oriented.

When we talk among us, as I/S professionals and managers, we recognise that executives and users of our companies are putting too much pressure on us, asking for systems and changes at an incredible growing speed and that the technologies and practices we are using (Structured Methodologies and CASE included) don’t help us enough. We also know that a lot of new technologies are emerging, also at a very high speed, which makes it very difficult for our departments to study and make use of all of them in the required time frame for our companies to continue to be competitive.

And we also easily recognise that this "incredible growing rate of change" is not only related to Information Technologies; it is also a dominant characteristic of the society we are living in and, of course also, of the business we are working in. When we look at management books and papers published in the last few years we can realise the importance of these changes: words like chaos, paradox, etc. are now a must.

We can easily agree that

- Businesses need profound changes and reengineering

- This will imply a great change not only in the technologies we use, but also in the way we see the I/S and its relation to the businesses of our companies

- Today business reorganization and the introduction of new information systems are closely related

- and both are in crisis!

But that brings us to the conclusion that major paradigm shifts are needed, and in fact are already occurring, in both I/S and business worlds (and also in all society).

Let me replace the exhibit on I/S changes for a new, updated one; even if I have not the intention of including all the shifts that are taking place or that are needed, you will still easily agree that a lot of change is occurring in front of our noses.

And the problem is:

- Is it too close to our noses and eyes that in fact we are not able to see it correctly?

- Isn’t it that all these changes can’t be "progressively incorporated" as we have done (or tried to do) with some previous ones? Isn’t it that a complete revolution will be needed in the way that I/S Managers, I/S Professionals, the Boards of Directors and the User Community see both Businesses and Information Systems?

- Isn’t it true that, as Peter Drucker stated in "The Coming of the New Organization" "the companies that we will work for in the future will be "Information Based"? In fact we can see today that those that don’t transform that way will collapse and we (the workers) will be obliged to move to others that are "Information Based".

And in this change, where all the business and I/S communities will be involved, what will be our role as I/S managers or professionals: will we lead the change or will we try to resist it?

I would like to present you now some of the major points which I think will be of the highest importance for that change which we are already involved in.

I must clarify that the points that I will refer to are not all of the same importance. Some of them are new concepts and, others are not new at all: but they are not accepted and/or applied regularly in all companies, or, if they are, there is, in our opinion, a strong possibility that they will be forgotten or overlooked if we will use some of the more common OO Methodologies.

The following exhibit shows the points that we consider to be the most important "Critical Success Factors" for the correct utilization of visual object oriented technologies in the years to come. They are also the main question that all the I/S and business professionals will have to address if they want to progress through the important paradigm shifts that we all will have to incorporate and manage.

- A model for understanding the I/S Management System within the Business

- Business and Logical Information Systems Architectures (Inter-related models of both the Businesses and I/S)

- A (new) model for the "reengineering and I/S projects" with two inter-related sides (or vectors)

- An iterative, version driven, development cycle.

- A True Object Oriented Methodology for I/S Architecture and Development supported by Visual case tools

- I/S Reengineering

- O.O.T. Pilot Projects and Education of I/S professionals

- General Management and user community involvement.

A MODEL FOR UNDERSTANDING THE I/S MANAGEMENT SYSTEM

The yellow IBM manuals on "Managing the I/S Business" have been of some importance. But they have become obsolete.

In a presentation to the 5th Portuguese I/S Congress, in 1988, I presented a communication where those models were reviewed. The following exhibits have been taken from that presentation and have been revised for this GSE conference.

To have a model for Managing the I/S System, to define what are the processes needed for that and how power, responsibilities and tasks must, in accordance to this model, be split among the different levels and divisions of the company (and no longer concentrated only in the I/S division) is now of utmost importance.

This implies understanding that the "strategic level" of the I/S Management must involve the Board and the Directors, and that at the tactical and operational levels the responsibilities must now be shared between I/S and the other Departments.

The importance of the processes on "Information Architecture" and "Data Management" are the areas that need a greater change. Today we prefer to speak about the "Logical I/S Architecture" and "Object Management" incorporating both methods (a process model) and variables (an information or data model).

In fact we cannot any more begin the I/S Architecture by a data model of the Organization that will lead to procedures (and programs) that will never inter-relate correctly. Relational DBMS’s and "data oriented models" have never fulfilled the expectations they have created and they are now trying to pretend that they are "object oriented".

It is very interesting to conclude that the purpose of the old IBM Methodology "Business Systems Planning" proved to be much more able to survive (with a lot of changes and modifications) than the "Information Architectures" data oriented methods (like BSDM, for instance).

In fact, B.S.P. was a methodology that, when applied to a company as a whole was intended to produce an inter-related "Business process and Information types model" (and not only a data model constructed upon the business procedures in use today). When combined further with other methods it could produce more detailed models for the different "sub-systems" of the business that continued to be simultaneously process and data model refinements.

We have applied successfully a methodology of our own that incorporates this simultaneous "process and data orientation", first at a macro-level and then at a more detailed level at "Banco de Portugal" (the Portuguese Central Bank) and later at the "Macao Electricity Company".

The models provided (that have been used as the base for a subsequent I/S Strategic Planning) were not only data models, but true "Business Process and Information Models" that have been used to configure Business Reengineering and application development projects, and were not biased by the organizational structure in place at the time.

The concept of "Business Objects" (the base for creating process and information models) was already used in both cases. The concepts of progressively developed models of both the Business and IS were already present which conducted us naturally to the visual, object oriented methods we have developed afterwards, and that we will present in the Berlin GSE October Conference.

Coming back to the projects that are included in the "Strategic Plans" we act as consultants for, the majority of them are also "process reengineering and IT oriented".

In fact we have been claiming for over 10 years that there are not such things as "reorganization projects" or "IT projects", that the majority of the project are simultaneously "reengineering and IT projects". This is now gaining wide acceptance.

And, as a consequence, an inter-related two sides project life-cycle must be used. In fact the one that we have been using in the "National Administration Institute", since 1980, can still provide a basis for this model..

Methods like JRD, JAD, RAD, etc. can continue to be used (and in fact make a lot more sense) with this model.

The idea of an iterative, version driven development cycle is also not new. J. Podolsky presented it in a very interesting article published in the "Datamation" of November 1977!

And in fact a release/version driven model has always been used by the software companies. So why not in I/S Departments within our companies? Why not for the internally produced software?

This iterative model could in fact be used with the old methodologies and can be combined with the two sides model already presented.

What the Object Technologies, with frames, ready made parts and reuse of objects and models will enable us will be to reduce the development time frame and use an iterative model with much more iterations in a given period.

The first thing that one can conclude when we analyse the available methodologies that claim to be Object Oriented is that there are too many.

The second is that a lot of them seem to be (bad) "object translations" of older methods.

Do you remember HIPO, and its Input - Process - Output diagrams? Don’t you see how this is close to some of the methodologies in existence today? Do you remember data oriented, entity models? Can’t you see some "translations" of those to an object like language?

We don’t pretend to have the good O-O Methodology, and in fact we don’t want to sell or

develop such thing. On the contrary we think, like Lawrence, that an eclectic perspective shall be adopted. There is no such thing as the Heaven Methodologies, nor such thing as the "good" or the "correct" Methodology. So different methods shall be applied for different subjects. And at the moment there is not a method nor a tool that can be considered the best.

But there are indeed methods that can’t be considered adequate. Like for instance the ones that are "entity oriented" (an object is not an entity), the ones that are I-O oriented, etc... And the methods to choose cannot be only Analysis and Development Methods - they have to be able to impose and maintain an object orientation from the I/S Architecture phase to the implementation.

And as we could already state at the Structured Methodologies time that (eventually) good analysis methods (like Mérise, Axial, SSADM, SDM, BSDM, etc...) could not be used for the Architecture phase (they were too detailed, good to see the trees but not the whole forest), we can also conclude today that some good O-O analysis and design methods can’t claim to be I/S Architecture Conception Methods, and so, they can’t be completely reliable.

What is needed is a methodology (or, eventually more than one) that can be used from the Architecture until the implementation.

And of course supported by visual case tools in all of those phases.

We have been talking about the need for

- Companies Business Process Reengineering

- Information based Organizations

- I/S Paradigm Shift

It is not difficult to understand that all this implies the need for I/S Reengineering that will encompass jobs, careers, responsibilities, etc...

This I/S Reengineering will not involve only the I/S Departments. I/S responsibilities will spread to all the functions and Departments, some current I/S responsibilities will go to other Departments or to the outside of the company (outsourcing, consultancy, ...) and some new responsibilities will be given to the I/S Department (Object Management, "New IT study and Proposals", etc...).

And one can discuss if the most valuable resources today (Information and People, that means, Knowledge) will not tend to be seen, in our companies, as two closely inter-related recourses, and if the "DP Divisions" and the "Personnel" or "Human Resources Divisions" will not tend to become in the future an "Information and Personnel Division" (or a "Knowledge Division" responsible for the Coordenation of all "Knowledge Mnagement", "Learning Management" and "Information Management" taking place in all the company).

The I/S reengineering process will be a progressive task that will incorporate training (recycling) of today’s professionals followed by reorientation to new methods and new careers.

At the moment O-O Technologies and methods are not mature enough, nor can our organizations forget the legacy systems and so we can not re-do all the I/S systems we are using to O-O principles.

But we can begin (we must begin) immediately, at least, some pilot projects using O-O.

And for that there is a need for education and training to the professionals involved. In our opinion that is being done, in many cases, in an incorrect way.

In what concerns programmers, in many cases, they begin using OOT by learning C++ (which is not a native OO language and does not impose a truly OO Thinking). So a lot of non object programs incorporating the C thinking are now written in C++. To teach OO to programmers we shall use directly better products like Digitalk Smalltalk and Parts or IBM Visual Age, for instance. In a comparison to the past, teaching "Structured Assembler Macros" to Assembler Programmers or Structured Compiled Basic to Basic Programmers was not the correct way to teach structured thinking and in fact led a lot of professionals to become unable to understand the new methods.

The same is true in what concerns the O-O training of analysts. In a first approach it seams that the natural way is to teach a methodology that allows them to make as much use of the old methods as possible. But the natural way is not always the best way!

When a paradigm shift is needed the old professionals shall be introduced in the first place to those methodologies, languages and tools that most impose the use of the new concepts, and not to those that replicate the old ideas to the new technologies.

Coad and Yourdon Methodology is a good one for initial O-O reorientation. Once analysts and programmers begin to "think object" any methodology can be taught. Important questions on what to do with legacy systems and how to progress from the structured designed systems and CASES to the new ones can then be correctly analysed. But that cannot be done before I/S Managers and Professionals gain a true understanding about what it means "thinking object" and what are the changes in the way of seeing the world (that means, what are the Paradigm Shifts) that are needed.

One last word for on already mentioned subject.

I/S decisions cannot continue, as they still are sometimes, to be made only by the I/S Departments: this is not good for the companies, nor for the I/S Departments and I/S Directors themselves.

We shall not talk only about informatics (informatique) management, but about "Organizational Information System" management. And when we talk about this much broader subject, we can easily come to the conclusion that the CEO and the Board of Directors must be involved in all the strategic decisions about IT, and that the User Community must be involved in the decisions, analysis and implementation of the new I/S (Sub-) Systems that will be used by them.

During the last 10 years I have conducted in-company Seminars for both the Board and Directors of many companies. And in the majority of the cases I have concluded (in accordance with the I/S management team of that company) that these seminars were of much more importance for the development of the I/S (and to the credibility of I/S managers and professionals) then any seminars or courses given only to the I/S community.

Eventually the future of I/S in the enterprises is (will) dependent of CEO’s and not of I/S Directors.