In the process of describing the Making of Enterprise Software – ALL-IN-1, I came across the ALL-IN-1 Philosophy we published in 1982.  I was impressed at how much I still adhere to this philosophy thirty years later.  This philosophy was the product of my collaboration with John Churin.  It is interesting to reflect on this philosophy as we experienced the evolution of office automation systems from ALL-IN-1 to Lotus Notes and to the present day of Microsoft Office and Exchange and Google Mail and Apps.

Behind the development of any major software product is a philosophy of why the product was developed and a model of the environment in which the product is expected to perform. Underlying the philosophy are also the business requirements of the organization funding the product development. This chapter (circa 1982) provides the major elements that went into the development of the Digital Equipment Corporation ALL-IN-1 product.

The following is a list of the major philosophical points:

1. Provide automated information access to the widest possible base of users.
2. Understand customer needs by focusing on solving today’s key business problems with today’s technology.
3. The needs of the office worker are evolutionary.
4. An automated office information system must be flexible to easily adapt to multiple user types, changing needs of the users, multiple input/output devices, and changing technology.
5. The system should appear as an integrated whole to the end user.
6. Office information systems tie into or touch all parts of an organization.
7. An office system should be self-contained.
8. The individual user should feel ownership of the system.
9. The user should be rewarded or acknowledged as an individual by the system.
10. The value of an automated system is only understood through demonstration of how functions are used to solve current key business problems.
11. The product development efforts should be directly funded by the customer base on the direct merits of the software.

1. Provide automated information access.

The goal of office information systems is to provide an information access utility for the widest possible population of users. The utility should provide the ability to access data no matter which computer system it resides in, either internal or external to an organization, so long as appropriate security conditions are met. The utility should then provide the tools for the user to turn the data into information. Once the information is created, it should be communicated to the appropriate people in an automated fashion. What is one person’s information may be another’s data.

This philosophy can be summarized by: getting the right information to the right person at the right time.

The user base should be thought of in its largest possible sense, not just the members of one’s own organization but also the other organizations that must be communicated to. Examples would be the exchange of paperwork that accompanies the exchange of goods and services between two organizations (purchase orders, status replies, invoices). In addition, information utilities are increasingly being shared by several organizations (Dow Jones, The Source, and CompuServe).

2. Understand customer needs.

The key to success is the understanding that office information systems are needed to solve the key business problems within an organization. The focus of product development and installation within the office environment should be on the business problem, not the available technology and what COULD be done. More than enough technology exists today to solve today’s problems; what does not exist is an understanding of how to apply the technology to specific customer needs.

Understanding customer needs is difficult to do in practice. Much time needs to be spent listening to the people who will use and have used office systems to understand their needs. Then “working models” need to be built quickly to determine if the users needs were really understood. In general, office users are not very good at stating their business problems so that we may build solutions. However, these users can very quickly observe a working model and determine whether the model meets their needs.

The key to success for the installer of an office information system is to find the key business problems within their organization and then use today’s products to start solving those problems. The key to success of the product developer is to understand enough different specific customer environments, abstract to the general solution for these problems, and then build a product which can adapt to specific user needs.

Early on in the development of systems which would meet customer needs we found that Digital had a superb set of tools which could be applied to the office environment. However these tools were designed for programmers, a very small portion of the overall user community. Our task was then to figure out how to take these general purpose tools and apply them to non-programmers for specific business problems. This application of using existing tools was born of necessity. We did not have the time, resources or funding to invent the perfect solution. We spent our time understanding available products and applying them to current problems.

3. The needs of the office worker are evolutionary.

The information access needs of the office worker are dynamic. Therefore the system must evolve to meet these needs. Our philosophy has been that the customer is pursuing a journey and not a destination. Office automation is really a process not a single product.

The process of accessing information is one that is practical; it is accomplished through trial and error, as there is no theoretical base for how an office worker performs their job.

Office systems need to be available at all times. This capability is actually an extension of the current environment, where the office is only accessible when one is physically in it. The logical extension of an automated system, is that it should be available wherever and whenever the office worker is available. Reliability is implicit.

Users will use the system in very different ways then ever intended by the implementor. User needs change rapidly over time.

Functionality before efficiency. This philosophy falls out of the rapid feature needs that most users find they want when exposed to a good system. These needs are more important than the relative efficiencies of the process. This philosophy assumes that others will provide the needed efficiencies primarily in the base hardware and software.

The system should evolve by adapting to the work patterns of the user. A logging mechanism is critical for this and many of our other philosophical tenants. The system should allow the user to modify the application to adapt to his work flow and where necessary the resulting procedure should become a permanent part of this user’s view of the system.

4. The automated system should be flexible and adaptable.

The automated office system should have a flexible structure and be able to adapt to a wide range of users and wide range of input/output devices. The types of users that the system must adapt to range from novice to expert, secretary to professional to manager. Input may come from a terminal, from OCR, from touch panel, touch tone phone, bar code readers. Output may go to other applications, printers, terminals, graphics or voice output.

Since there is such a variety of users and devices that the system must interact with, general purpose tools were used as the starting point. These tools allow the application programmer to build working models quickly as well as modify them to suit different users or different input/output devices.

Most vendors are supplying the same types of base functions: word processing, electronic mail, calendar, desk management, data processing, and graphics. Each vendor can pull out an impressive feature and function list. However, most of the applications were not designed to work together and the user has to manually move from application to application. Since these systems generally hard code the user interface in each application, the customer is unable to modify the interface to the function or modify how the function performs.

What attracts most customers to ALL-IN-1 is the ability to have a user interface which ties very diverse applications together. At the same time this interface may be customized to suit the local users needs. With this interface, programs and applications which were used by programmers can be extended to office users.

5. System should appear as integrated whole.

To provide a system which is easy to understand and use, the system should achieve a high level of integration. The individual components should appear to work together and be part of the same structure.

Integration can be viewed as a spectrum:

<—- Features —- Common Structure —- Integrated Only System —>

At the Features Only end, applications are developed as independent entities. The user must come back to a command level before accessing the next application. Data or information is not automatically passed from one application to the next. An integrated system would be developed from scratch and would have all applications tightly coupled to the others.

There is a natural conflict between features only and full integration. It is very easy to develop features only and extremely complicated to develop an integrated system. Further, the integrated system is very difficult to modify, as a change in one application could potentially affect all other applications.

Due to the dynamics of the office environment, we felt that a fully integrated system was not possible. Rather, a common structure should be built of independent modules that would have a common flow control for moving information between the independent applications without the user at the terminal having to do so manually.

6. Office systems touch everything within an organization.

Since data arises in almost every part of an organization and outside of it, office systems must be able to access the data to turn it into information and then be able to communicate with all other systems. Likewise, just about every data processing product ever developed interacts with an office information system at some point.

The office environment will be multi-vendor so it is vital that a full function communication architecture be available that allows for easy information transfer between systems.

7. System should be self contained.

As far as the end user is concerned the office system should be self contained. All documentation, help, key concepts, and computer based instruction should be available through the users terminal. The user should not have to have a mass of documentation to operate the system nor require extensive training away from her work environment. The system should be able to start being used immediately. Thus, our philosophy pushed us to develop all collateral material in machine readable format for inclusion with the system.

8. Individual should feel ownership of the system.

The users of the system should feel like they own it in much the same way that they take ownership and personalize their own desk environment. Further, the individual should have the ultimate control of what happens within his environment. Other users should not be able to invade his environment without the permission of the individual. Examples are: incoming mail should not go into the users file cabinet until he says to do that. Meetings should not be permanently scheduled unless the schedulee is aware and agrees to the meeting.

9. User should feel sense of reward.

The user should have built in rewards from the system. The system should acknowledge that there is an individual. Examples of acknowledgment: the user should have the main menu built from a single entry for Computer Based Instruction (CBI) to the total list of functions that he has gained an understanding of by going through the appropriate CBI (avoid the ALL-AT-ONCE syndrome). The system should analyze the log files periodically to detect work flow patterns or the need for more training in areas that the user has not used. If a user is entering orders, the system might come out with an acknowledgment at suitable intervals (every 1 Million dollars) or let the user know how many clean orders they entered.

10. System value understood only through demonstration.

People rarely think about what they do in their current office environment. We have found it extremely difficult to talk about what an office information system is or how it should be used. The users only understand the value, once they see a demonstration of the capabilities. An analogy is how we learn to drive a car. We don’t do it by reading about it, we do it by watching and then practicing.

11. Product development should be directly customer funded.

The development efforts for office applications should be directly funded by customers. This philosophy was born of necessity but has been key to the motivation of those involved. It places an emphasis on using existing products instead of inventing new ones, and keeps the development focus on solving real problems instead of inventing solutions which no one wants. A fallout of this philosophy is a built in marketing test, that is, if one customer is willing to pay for the development, chances are many more customers are, since the generic office needs are quite similar in large organizations.