by
HEINRICH REINERMANN
German University of Administrative Sciences Speyer
(in: Computers, Environment and Urban Systems, An International Journal, Vol. 11, No. 1/2/1986, pp. 73-80.)
In the 1920s and 1930s, people on both sides of the Pacific Ocean looked up to a movement which originated in Germany and spread all over the world, a new and somewhat revolutionary understanding and style of modern architecture and design - the Bauhaus movement. Today, people in Germany look up to the giants in information technology on both sides of the Pacific.
Whereas the international success of the Bauhaus movement was reflected by the American phrase "in Europe they do it better", today the know-how in information technology is concentrated around the Pacific.
Therefore, I consider my proper role in this congress to be that of a listener and learner. But I want to contribute a little bit to the program - an analogy between the Bauhaus style of design and the design of information systems for local administrations.
Let me first sketch the automation scene in German local communities.(1)
The most striking feature here is probably the comparatively intensive computer use: 1980, in Hesse (1 of our 11 states and a typical example) 412 among 422 communities below the county level utilized EDP; this equals some 98 %.(2) Compare this to the United States where, in 1980, only 51% of all local communities above 10,000 inhabitants utilized EDP.(3)
As a rule even the smallest local administrations in Germany use EDP. The reason behind this feature is a network of some 70 public computer centers all over the country which serve as regional cooperatives. They were established around 1970 when the governments of our 11 states felt that the development of EDP use, until then had been too uncoordinated and should be substituted by a system of institutions and procedures for the planning, coordination, and realization of EDP application in administrations. The individual setups in the 11 states differ somewhat. But, as a general rule, a local community is a member of a regional cooperative which provides for computer capacity and software. Automation policies, application development and so on are decided upon by a board of delegates of the member communities.
Thanks to this strategy, the benefits of computer use could be brought to a wide range of communities quickly and at low costs.
But, over time the quality of services offered by some of these institutions deteriorated. Today, quite a few local administrations complain about:
Dissatisfaction with the products of our EDP infrastructure has several reasons, among them:
On the one hand this dissatisfaction had led quite a few communities to the installation of autonomous computers; on the other hand it has caused the infrastructure to reconsider their role and proper strategies for a successful cooperation with member communities. And here is where the Bauhaus analogy comes in.
The beginning of the 20th century experienced some dissatisfaction, too, here dissatisfaction with industrial mass production. Compared to former high-quality products, tailor-made or manufactured in small quantities by artisans, industrial mass products often were poorly designed and poorly made.
The new customer demands, caused by rapid economical and sociopolitical change, were not met. Among these fundamental changes were:
On the other hand, there existed a new supply:
Why hadn't this new technological supply been utilized to really meet the altered demands of the people? Besides similar movements like "Deutscher Werkbund" or "de Stijl", the Bauhaus movement tried to be an answer to this question. Its first institutionalization was the State College for Art and Design, founded 1919 in Weimar (the new Capital; later, the school was moved to Dessau and Berlin, and in the late 1930s, to Chicago, among others).
The idea was to "secularize" art and to utilize it for better and cheaper design of daily life goods and products - from houses and furniture to household supplies and decorative equipment. Daily life goods should become adequately designed, and, nevertheless, be within the means of the people.
Notice the analogy to the overall situation of automation in local communities. Here, in the 1960's and 1970s, we had fundamental changes as well:
And there was a supply, too, to meet some of the demands: electronic data processing. But, as we have seen above, at least some of the responding expectations have not been met yet because some EDP systems have been poorly designed and deliver centrally made "mass products".
Has the time come to launch a Bauhaus movement for the design of information systems in local administration? Let's have a look at some characteristic aspects of the Bauhaus (here, instead of trying to describe the Bauhaus as such I restrict myself to features which seem to be of interest for local information systems).
Modern technology (steel, concrete, synthetics, and mass production methods) was seen as a challenge and a chance to overcome the negative side effects of the industrialization of society. The Bauhaus intended an alliance between art and industry. The potential of new technologies should be utilized to the benefits of the people.
Beyond that, however, the founders of the Bauhaus were weil aware of the fact that negative side effects of modern technology could not be avoided, given the until then prevailing "laisser faire"-behaviour. They called for a conscious process of planned design and construction.
In short, the Bauhaus accepted modern technology, but, at the same time, intended to manage it.
Regarding information technology today, however, we in Gerrnany observe opposition instead of acceptance. Alliances between artists and ecology are much more frequent than between art and industry. Boycott, even demolition of information systems happens. Technology assessment often is more or less another term for apocalyptical negation.
lf art and design are to be "secularized", you have to start with user needs and expectations. This is a very important aspect of the Bauhaus concept. What are the ends and purposes of a product? To answer the question, a Bauhaus architect for instance was taught how to measure the needs (in terms of space, air, light, traffic arrangements etc.) of the future occupants of a house: family sizes and structures, communication habits, occupations, incomes, size and location of the lots, character of the surrounding landscapes, the climatic situation and so on, had to be taken into account.
Regarding information systems in local communities, have we cared enough about the definition of user needs, about their expectations? Have the users tried hard enough to make the computer centers fulfil their needs? The answer quite often is "no".
According to the Bauhaus concept, design had to pay special attention to the function of a product. What is its real nature, its essence, its "soul"? Having answered this basic question, the designer was supposed to abstract from traditional ways in which the function has been brought about. Instead, the Bauhaus favoured a grass route's approach: having new materials and production methods at our disposal, isn't there a different way to fulfil the functions of a product? "Form without ornament", "form follows function", no more "Kitsch for the rich", those were typical Bauhaus phrases. They led to courageous, resolute, "modern", sometimes radical approaches to new designs, frequently with rectangular or cubical patterns and without colours.
Here, too, the analogy to local administration information systems is obvious. Very often we have put administrative procedures on the computer as they had been carried out traditionally. Seldom have we questioned the organizational structures and methods in city halls, in favour of a fresh look to whether modern informätion technology could allow better ways. lt is probably not too wrong to compare today's local information systems to the time when gasoline engines were "added" to stage coaches, when the potential of this new technology had not been used yet to construct a new-style vehicle which was able to perform the functions of transportation in a genuine way.
Another important feature of the Bauhaus movement is entirety of design. The house and its environment, the apartments, the furniture, the decorations everything was supposed to fit together, to form an entity ("the great building").
Compare this to EDP in local administration where, quite often, we find "stand-alone solutions" or separated applications which are not integrated. A typical example is citizen registration packages and databases on the one hand, and finance packages and databases on the other hand. Even more important: very often there is no "entirety" of tasks, organization, personnel, and technical equipment.
Careful design in accordance with these criteria is expensive. lf it is to be to the benefit of the people, the costs must be distributed to many applications. Only then, good design becomes affordable. Therefore, standardization was one of the goals of the Bauhaus. The invention of combinable furniture is an example. Another aspect of standardization is the development of product models or prototypes which then could be produced in large charges by industrial companies. Aptitude for mechanical production was considered a criterion for good design. By restricting standardization to moduls or to parts of products, the positive effects of both, cost distribution and individuality of the user, seemed to be attainable.
Doubtless, standardization is important for today's local information systems, too. lt would be a waste of the taxpayers' money if each community tried to "re-invent the wheel". On the other hand, regional cooperatives often have driven standardization too far. Prototyping, modularity of both, hardware and software, seems to be a necessary strategy of design.
The Bauhaus put a high emphasis on solid knowledge of modern technologies. Only architects and designers who really know about the properties of materials and production methods are able to utilize their full potential. Special courses of the college were reserved for this purpose; departments were called "Workshop", professors "Master".
Obviously, this concept is important for those, too, who are in charge of design of local administration information systems. Without solid knowledge of public administration on the one hand and of the properties and potential of information technology on the other, satisfactory results of automation in local communities cannot be expected.
Of course, we all know that quite a few of these Bauhaus concepts never became reality that some of the good ideas remained just intentions. Today, besides modern and thoughtful design, the term "Bauhaus" also leads to associations like:
How could this happen to a movement that, in reality, wanted to secularize art, to serve the needs of the people? I think some of the reasons are:
A typical example is the constant adherence to flat roofs even in rainy areas of the globe, combined with the rejection of gutters. Result: those roofs almost always leak and the walls look ugly. Certain design concepts simply became principles of a paradigm which were not to be called in question.
The deeper cause probably is: exaggerated structuralism. If you happen to belong to those who know the "real nature of things", their essence, then, of course, you don't have to worry about user participation and praxis tests. On the contrary: they only hinder "progress". And if people don't like your designs, they just demonstrate to live in the backwoods.
A lesson of the Bauhaus movement for architecture and design, then, could be: utilize its strong concepts like positive attitudes towards technological progress, user needs orientation, functionalism, entirety, standardization, and knowledge orientation - but, by all means, combine them with practical tests and user participation. Such a design appraoch might be just as necessary to overcome today's disadvantages of automation in public administration as it was necessary to overcome negative effects of the beginning industrialization.
However, I do not agree with those critics who accuse the Bauhaus (or similar movements) of having had a too narrow scope and of having been too optimistic in respect of a possible harmony between the interests of industrial companies (capital owners, that is) and the people. "Proofs" for this failure are seen in ecological damages or in boring, dull satellite cities. These critics consider the Bauhaus concept to be a "nice try", but too much centered on "detail problems" as form and function of industrial goods.
I don't agree because:
(1) naturally, the Bauhaus tackled the problems of its time;
(2) certain needs only arise when other needs have been satisfied. Only some time after people had moved from narrow, noisy, dark, old-fashioned cities or early public housing blocks to spacious, green, luminous, modern satellite towns, they realized the need of communication. It will never be possible to foresee all future needs during a phase of design;
(3) it is legitimate - and necessary to concentrate a design on certain aspects. Even concepts like functionalism or entirety do not mean that each design approach has to resolve all the important problems of society. On the contrary, such a view only would lead to immobility because nobody ever has the power to surpass all the restrictions, seen by the "system critics" (revolution excepted). Normally, progress can only be made step by step, and with trust in the division of labour: not all the problems are the concern of the same designer.
Transferred to local administration information systems, an (improved!) Bauhaus-type redesign today seems to be appropriate, even though a city that tries to apply it, of course is not able to solve all "ecological" problems of information systems (like potential unemployment or endangered privacy).
In order to demonstrate that in German local administrations there is a need for an active design concept, I would like to use the state of automation in two typical local agencies as an example:
Both administer data of inhabitants:
The registry office keeps registers of births, marriages, and deaths which have happened within the boundaries of the city (notice that the respective people don't have to be citizens of this city). These data are officially signed and attested; they have notarial quality.
The residents office keeps records of all the citizens who actually live in the city, especially of their residences. These data are used for citizen identification, for registers of electors, of school beginners, of vaccination candidates, of persons liable for military service, for the printing of tax cards and so on.
By tradition both, the registry office and the residents office, are independent, organizationally separated agencies. And their databases are separated, too, although the bulk of these data is identical: first and last name, address, date of birth and so on. This organizational set up, useful in earlier times, causes quite a few negative side effects which, today, seem to be avoidable, given the potential of information technology:
As far as automation is concerned, the situation in both agencies is very different. Some observers claim that the registry offices still prefer to use quill pens and to communicate by stage coaches. True is that here utilization of modern information technique, word processing included, is only beginning, in spite of the fact that certifications, verificaticns, and authentications make up most of the work. Reasons are a certain tendency towards tradition on the side of the registrars, a dense net of regulations rooted in the notarial functions of this agency, complicated, old-fashioned forms, or the law that registers of each year have to be kept as bound books (which even makes it difficult to use a photocopier for extracts).
Citizen registration, on the other hand, usually is highly automated. Residents files are kept electronically; tax cards, all kinds of listings (like school beginners, electors etc.) are printed by the computer. All things considered, computer use in citizen registration has had many positive effects. But, often there are still severe deficiencies, especially when cities are linked to a central regional cooperative computer which only offers batch processing. This is still the case. Here, the computer is used mainly as a fast typewriter. The potential of modern information technology for direct access to files, online information etc. is not utilized. In addition, complaints are not seldom that the EDP systems do not even offer small letters or special types (e.g. modified vowels) or that certain routine tasks of residents offices are not supported yet by respective software packages (e.g. notification of the police, of churches, statistical agencies and so on, about changes in city population).
Of course, this way of automation in registry and residents offices can cause a broad range of shortcomings for administrative efficiency, for citizens and employees, e.g.:
What this example should demonstrate is that, in fact, after some 20 years of EDP in local administration and in spite of many positive results, we do have reasons to be dissatisfied with some of the products. There is some necessity for a design concept which stresses user needs, functionalism, and entirety.
What would a Bauhaus-like design of an information system for registry and residents offices in local communities look like?
At first, the organizational structure should be adapted to today's technology. The two traditionally separated agencies should be integrated ("citizen office"). They should use the same integrated and computer supported database.
This would allow a new arrangement of compentenc es and job descriptions: the registrar for example, when he has to attest a birth in a family which also lives in the city, could:
When persons move to the city, the residents files, as today, should be supplemented by the residents office. But the registrar should get a new task: to check and attest such new data.
Thus, over time, all residents data in the computer would be attested. And since both, registry and residents office have direct access to this database, this new organizational arrangement would have many advantages:
Such a design (which of course, would have to be complemented by a respective EDP installation with online access to the database, bill feed, form printers, word processing etc.) would serve several needs:
Taking the potential of modern information technology into account, many more questions with respect to citizen administration arise, like:
This simple, nevertheless real, example hopefully proves that there is, indeed, much opportunity to redesign local administrations along the lines of Bauhaus concepts. Having new technologies at our disposal, a fresh look at administrative structures and procedures, at their real nature and functions, at user needs, seems promising. Rather than to add new pieces of information technology to city halls as they are, we have to take the entirety of tasks, organization, employees, citizens, and goals into account.
Why didn't all this come about yet, anyway? There are several reasons, for instance the complexity of early computers, the constant and rapid change of information technology. But the main reason seems to be that top and middle management in local communities very often have failed to fufil their responsibilities. Instead of active control, they left the introduction of EDP to technicians and computer experts. EDP was considered to be just another neutral technique. But, as the example proved, this is by no means the case. Automation offers many and important political and economial problems which should only be solved by council members, mayors and other managers in local communities. Here, one more time, an analogy to the Bauhaus seems appropriate: the establishment of a local information system can be compared to the construction of a house. Which groups are involved and what are their proper roles?
Most important is the building owner. He has to define his goals and restrictions and those of the future inhabitants. But, in order to do this right, he needs the help of architects, they know about design and technical alternatives and about costs. Only in cooperation of houseowner and architect, a "blueprint" should be developed which, then, is the workplan for the building contractors.
As a general rule, in Germany, top and middle local managers still have to learn this role of the owner when it comes to decisions about information systems. Different from schools, hospitals, or city hall buildings, automation often is not treated as an investment which should be based on discussions and decisions about needs, alternative drafts, benefits and costs. However, in order to avoid the extravagance of some Bauhaus designs, management in local communities has to make sure that citizens and employees get their chance to influence the decisions about user needs and administrative functions.
Regarding architects of inforrnation systems, we are in a comparatively good position. Our regional cooperatives have the knowledge about public administrations and about modern technology as well. Sometimes, they still are too centralistically minded. But if regional cooperatives are to stay in business, user needs orientation is a necessary prerequisite. Like an architect, the regional cooperative should consult its customer communities, but, lastly, solve the problems of the "owners" of information systems and not those of the computer center. Having some 8500 local communities in Germany and, roughly, up to 100 cities linked to a single regional cooperative, there is a promising market for service products and there is a good chance for standardization both of organizational analysis methods and of software modules.
Only when owners and architects have fulfilled their duties and have agreed on a "ground plan", layed out along the lines I have sketched for citizen administration, the building contractors enter the game. In information systems, they are represented by computer manufacturers, software houses and computer centers. In the past, because of the lack of active design of information systems by local managers, they often have ruled the scene and taken over the roles of owners and architects, too. However, not technological feasibility, but assessment of the real needs of a community should be the guide of automation.
To sum up, I think there really is some necessity for a Bauhaus movement in the fields of our local administration information systems. After some 20 years of EDP, we should lean back and ask ourselves what has been reached and what we don't like. We should accept modern information technology (there is no way out, anyway), but bring it down to earth and manage it clearly - lastly the duty of city councils and mayors. With the help (not: under the dictatorship!) of architects, they must decide what kind of automation and, in accordance with that, what kinds of administrative functions and structures they want.
Thus, when we try to utilize the positive aspects of the Bauhaus (as acceptance of modernity, needs orientation, functionalism, entirety, or standardization) and to avoid the pitfalls (as exaggerated structuralism, monotony, esoterism), we have a good chance to be well "accommodated" in automated city halls.
Tom Wolfe has written the excellent and sensational, although biased and (sometimes too) sceptical book From Bauhaus to Our House.(4) He will forgive that we adapted his title for this contribution which is superscribed "From Bauhaus to Rathaus". But, isn't the Rathaus our house, after all?
(1) For more infonnation see Konig K., von Oertzen H-J. and Wagener F. (Eds) Publie Administration in the Federal Republic ofgermany, Kluwer, Deventer, The Netherlands: here, H. Reinerrnann, Quantitative and Data Processing (1983).
(2) See Hessische Zentrale für Datenverarbeitung, Company Report 1980, p. 6. Wiesbaden (1981).
(3) See Kraemer K. L. and King J. L. Management science and information technologies in U.S. local governments: a review of use and impact. Comput. Environ. Urban Systems 7(112), 7-19 (1982). Here p. 13.
(4) Wolfe T. From Bauhaus to Our House. Fairar/Strauss/Giroux, New York (1981).