2. Architecture, engineering and understanding

Successful methodologies have been built around the notions of architecture  and engineering , as applied to information systems.  These metaphors have been useful, and lessons from those en-deavors have helped the information systems profession make great strides over the last decades.

An engineering perspective will always be critical to the success of information systems with re-spect to performance requirements of hardware and network components.  On the other hand, when architecture and engineering are taken to be sufficient models for what information systems are all about, a fundamental conceptual confusion results.  The following quote presents the nature of this confusion:

“When applied to an information system, the word architecture is a metaphor that compares the construction of a computer system to the construction of a house. …  Enterprise or business model[s are analogous to] … the architect’s drawings that depict the final building from the perspective of the owner, who will have to live with it in the daily routines of business.  They correspond to the enterprise (business) model, which constitutes the design of the business and shows the business entities and processes and how they interact .”  

In this passage, a computer information system is made analogous to a building (a house or a business structure).  It is stated that an enterprise model is both a model of an artifact (building) and the business served by that artifact.  This is like equating a house with the family that will live in the house.  Clearly a house and a family are not the same, and cannot be described by the same model.  A model of a family, including the number of members, interests and hobbies, ages and expected growth patterns, would be very useful input into the design of a home.  In the same way, a model of the business provides very useful input into the design of its information systems.  The point is, they are different models.

Understanding user requirements is widely acknowledged as a critical success factor for information systems.  Many methods, even when they address business issues, do so from the perspective of a particular system development effort, looking outward (see Figure 1).  The very words  “requirements" and "user" reveal the perspective from inside some (proposed) information system.  All we need to do is ask "Requirements for what?" and "Users of what?" to see that perspective.  The answer must be “Requirements and/or users of some information system”. 

 
Figure 1

In contrast, the perspective that underpins business language analysis (Figure 2) is from outside the enterprise, looking in at the human systems, and the information systems that compose that enterprise.  This perspective forces examination of the information needs of the enterprise as a whole.  It can even embrace an extended enterprise, which reaches out to incorporate external enterprises as part of a larger human system.

 
Figure 2
A human-centered approach to information management provides the underpinning for business language analysis.  The perspective of business language analysis is less on engineering, and more on understanding.  It recognizes that it is a losing proposition to try to engineer human communication.  It aspires to understand the meaning of communication within the human activ-ity system so as to support the evolution of the business, along with its information systems capability.