October 1998                 Issue: 5

Journal of Conceptual Modeling
www.inconcept.com/jcm

Where is the "Engineering" in "Information Engineering"?
by Dr. John K. Sharp

Accountability is the core parameter that allows an engineering discipline to consistently provide value to a corporation. Each engineering discipline has its own terminology and rules that must be understood and then followed. Accountability is enforced through engineering procedures that assign responsibilities to skilled participants during the phases of the production lifecycle.

As an example of an engineering discipline let us review a new part that is to be built involving a mechanical engineer with the idea, a design draftsman who documents the design and a craftsman who makes the part. When the mechanical part is being developed, an accountability chain is well understood by all of the participants.

If the craftsman built the part according to the design, then the craftsman did the right job. This does not mean that the craftsman should not give feedback to the designer and/or the engineer if he/she has knowledgeable input, but any input that is accepted will be fully incorporated in a new issue of the design.

If the design draftsman created and documented the design according to the established procedures, then the design draftsman did the correct job. The design draftsman should also provide knowledgeable input that, if accepted, would be formally documented in the design. If the design draftsman followed all of the engineering procedures in creating the design then he/she did the right job.

If the engineer specified a part that works (meets the form, fit and function requirements), then the engineer did the right job. The engineer should accept input from the development team, but he/she has the responsibility for the part. If everyone followed the correct procedures and the part works, then all of the participants get the appropriate rewards. If the engineering procedures were properly carried out in the design and construction of the part and the part does not work, then he/she is accountable for the results.

Even with an understood procedure based upon a common language (terminology, procedures, and design documents) is used, mistakes are made. The value of the engineering discipline is when something goes wrong. If the part fails for some reason, then either the procedure failed or one or more of the participants are accountable. If the procedure failed, then all future design efforts can be improved by correcting the procedure. If a person is responsible, then the responsible person can have an important learning experience and possibly need more training. In either case, the problem has a good chance of not being repeated.

Although the proceeding description is an idealistic version of an engineering discipline, contrast it with what is acceptable in the information lifecycle. Information systems have a subject matter expert (engineer), an analyst (design draftsman), and an implementer (craftsman). Analysts and implementers have a wide variety of tools that are available to improve their productivity. The problem with these tools is that the experts are usually only superficially involved in the knowledge content of the design that is documented with the tools. The documented design cannot be read or validated by the subject matter expert and thus he/she cannot be held accountable for its contents. Furthermore, the documented design is usually not complete and the implementer is required to talk to the subject matter expert as well as the analyst and possibly others to figure out what should be delivered.

Finished projects are routinely rejected and then the projects must be reworked or just dropped. In the effort to create the desired application all of the participants could have done the right job and the project would still fail. I know of cases where the subject matter experts have been turned into IS analysts because the IS analysts could not do the required job and cases where the IS analysts have become the subject matter experts by default. The amount of wasted corporate resources is significant in all of these IS efforts.

You know the number of projects that have been abandoned or were less than successful in your own company. Statistics have been collected that show that over half of the errors in implemented systems can be traced to errors in the design. Other reviews have shown that nearly all information systems fail to meet initial cost, schedule and functional objectives [Jones]. With this history it is understandable that management continually distrusts the IS capabilities inside and outside of the company.

No other engineering discipline could exist with this type of track record. The company would have long since gone bankrupt. But as we know computers are special and required. We in the information community have an obligation to improve our procedures so that we can really become an engineering discipline.

One goal of the NIAM/ORM/NLM methods is to have designs that are better understood by the subject matter expert and are more precise. Procedures can be established for these methods that can make more individuals accountable for the resulting application. Setting up these procedures for information system design should be a strategic goal for every company.

NLM is an Engineering Procedure

The Natural Language Modeling (NLM) analysis procedure qualifies as an engineering procedure for information system design because accountability can be assigned to all of the involved parties. The subject matter experts are accountable for the design. The analysts are responsible for following the NLM procedure and preparing models that are logically complete. The implementers are responsible for constructing applications according to the design.

The NLM procedure for sentence analysis has six steps that take an input sentence and establishes all of its fact types using only input from subject matter experts. While the subject matter experts are accountable for the design, other experts can independently validate the design. None of these experts are required to understand any aspects of the modeling procedure or understand a graphical presentation of the modeling results. The analyst understands and follows the NLM procedure, but functions only as a catalyst for extracting the knowledge. She does not create any knowledge by herself.

Figure 1: NLM Procedure Steps

Step 1 Verbalize Sentence: The subject matter expert creates a sentence. The sentence usually comes from a populated example. It is helpful to highlight the portion of the example covered by the sentence to ensure that all placeholders in the example are included in a sentence. The sentences presented here for illustration are from a security system model.

On 7-16-97 at 16:55, the active sensor 3867 detected movement.

Step 2 Assign Placeholders (variables): The subject matter expert is then requested to supply a second sentence that has all of the possible varying elements changed. A placeholder location is assigned for each varying element.

On 7-16-97 at 16:55, the active sensor 3867 detected movement. On 7-18-97 at 12:55, the inactive sensor 3473 detected no movement.

Step 3 Qualify Tokens (instances): The tokens (instances) in each placeholder location are then qualified. This consists of assigning an object or class, a label and a placeholder name for each set of tokens.

3867 and 3473 are each a Sensor Number (label) of a Sensor (object or class). The placeholder name for the position where 3867 and 3473 appear in the sentence is <SensorNo>.

Step 4 Identify Objects: Before the sentence can be analyzed each object represented by a token must be properly identified. This involves creating an existence sentence for each object represented by a token. The sentence is then tested using the NLM procedure to determine if the token is an identifier of the object.

Sensor with sensor number <SensorNo> exists.

Does the sensor number 3867 at any moment in time exactly identify a sensor? Yes

The example presented here shows how the subject matter expert validates that a sensor number identifies a sensor. The first question is "Is more than one sensor allowed in the subject area?" The second question is "Does a sensor number exactly identify a sensor?" The expert's two Yes answers establish an identifier for the "Sensor" object. All model results can be directly traced to the expert's answers to simple questions. Other subject matter experts can directly validate the model results by reviewing and agreeing with the answers. In this case the identification fact type can be stated as:

Sensor number <SensorNo> identifies a sensor.

Step 5 Validate Fact Types: Once the objects in the sentence are properly identified, the sentence can be analyzed to determine the elementary units of knowledge (elementary fact types) contained in the sentence. The deterministic NLM procedure processes the Yes and No answer vector in the matrix to extract the elementary fact types from the sentence.

On <Date> at <Time>, <Status> sensor <SensorNo> detected <MovementReading>.

Again, these answers come directly from the subject matter expert. The expert is thus accountable for the results. Other experts can independently validate all of the answers. The progress through the NLM procedure depends only on pattern recognition using a series of Yes and No answer vectors. The elementary fact types contained in the original example sentence are:

On <Date> at <Time> sensor <SensorNo> detected <MovementReading>. On <Date> at <Time> sensor <SensorNo> has <Status>.

Step 6 Restrict Populations: Once the identification and elementary fact types are determined then the subject matter expert is asked if there are any restrictions on the population of a specific fact type. Restrictions include value constraints, derivation rules (e.g. the value is calculated from other fact types.) or any set theoretic restriction (e.g. subset, exclusion, equality, etc.)

In this example, the identification fact type:

The status type <Status> identifies a status.

has its population restricted with a value constraint allowing only{active, inactive} as tokens.

The process continues by analyzing each new sentence until the whole subject area is captured. There is also a graphical way to present the NLM knowledge, but any graphical methodology that supports relational or object oriented implementations can present knowledge specified with this analysis procedure (although some methodologies can present a larger portion of the knowledge.)

Conclusion

Accepting the cost of unsuccessful IS efforts without understanding what went wrong should not continue. A deterministic analysis procedure such as NLM provides a way to directly assign accountability. Problems can be identified and internal procedures can be modified as required or the responsible individuals can receive appropriate training. Does your company have an engineering procedure for the design, development, and/or purchase of information systems? What is the primary strategic IS issue being addressed by your company this year?

Happy Modeling!

Casper Jones, Software Quality Forum, Sandia National Laboratories, April 1-3, 1997, Albuquerque, NM

Dr. John Sharp is the founder and principal consultant for Sharp Informatics.Before starting Sharp Informatics in 1997 he was employed by Sandia National Laboratories in Albuquerque, NM for 18 years. While at Sandia he held staff and management positions in all areas of information technology, including analysis, design, implementation, maintenance, information architecture, data administration, and information technology research. He has worked closely with Prof. Shir Nijssen of The Netherlands to improve the NIAM analysis methodology. Dr. Sharp is the creator of the first information analysis procedure known to be mathematically precise.This procedure reformulates the usual (imprecise and inaccurate) statements and examples from a subject area into verified fact types. The output of this productivity enhancing process (a set of information requirements) is compatible with all the latest and most productive database application creation tools. John is the editor of the international standard for conceptual schemas. He has co-chaired two international conferences on natural language modeling and he has presented numerous papers and seminars at professional conferences.

Contact information:

Dr. John Sharp
Sharp Informatics
1604 Vassar SE
Albuquerque, NM 87106
sharp@sharp-informatics.com
505-243-1498
fax 505-248-0345
http://www.sharp-informatics.com

© Copyright, 1998-2004 InConcept (Information Conceptual Modeling, Inc.) All Rights Reserved. Privacy Statement.
ISSN: 1533-3825