Gordon C. Everest

Building an IS architecture: collective wisdom from the field

Abstract This paper is the result of two years of discussion sessions with a group of managers responsible for the development and maintenance of IS architectures. The paper refines the definition of IS architecture and puts it into broader perspective by defining a set of concrete, thus more manageable sub-architectures: process, data, control and technology architectures. The resulting IS architecture framework should help the management develop a clear understanding of their critical information resources and guide them toward more effective planning and management of those resources. The IS managers in our discussion sessions shared their experiences in developing and maintaining IS architectures for their organizations. While their initial experiences were not very successful, they recognized the benefits of having a well-maintained IS architecture. They were also confident that the shared knowledge would help them avoid the pitfalls they had previously encountered and enable them to develop a successful IS architecture.

Assessing user experience with CASE tools: an exploratory analysis

The paper reports on the results of a survey of 19 large organizations in the Twin Cities of Minnesota. The survey gathered data on the experiences, expectations, realizations, and suggestions regarding the use of CASE tools. It focused on what they considered to be the critical success factors in the introduction and use of CASE. Most organizations had strong management support and a high ranking executive to champion the adoption and use of CASE. More organizations had made a commitment to use construction tools than design, and to use design tools than planning tools. Larger organizations were further along in their commitment to use CASE than smaller organizations.<<ETX>>

The futures of database management

This paper explores some futures of database management. A review of the historical development of database management facilities reveals a dichotomy of systems into host-language database management systems for application programmers, and self-contained database management systems for nonprogramming users. Development trends indicate that future systems will combine facilities to serve both the programming and nonprogramming users, will be functionally more complete, and will offer greater data independence and a simpler user interface. The CODASYL Data Base Task Group proposal is the only possible candidate for a standard yet it still presents some serious weaknesses. With the development of systems based upon Codds relational data model, IBM could become a dominant force in database management systems in the next decade. Emerging technology includes computer architectures with functionally-distinct, asynchronous processors some using associative processing techniques. A separate database management machine can yield better performance and greater data integrity.

The Objectives of Database Management

This paper is intended for both corporate management and the technical information specialists who are concerned or responsible for the proper management of corporate data resources. For corporate management who both use and make decisions regarding the use of database management systems it provides sufficient detail to appreciate the fact that some difficult technical problems underlie the objectives. For the technical information specialist it provides a broad view of what might be the major objectives of database management, to understand how some of his technical problems and the things that are treated lightly in today’s systems really do fit into the larger picture of management. In a sense it is intended to establish a common ground of understanding between management and the information specialist—a ground from which dialogue and negotiation can spring to their mutual benefit. The assumed context of database management systems is management information systems in the business organization. This context is selected for its richness, diversity, and changeability. When management repeatedly deals with a problem area they produce a procedural manual, delegate the handling of the problem to others, and accept the challenge of dealing with new problems and new concerns, and of reaching new horizons.

Evaluation and Enhancements for NORMA: Student User Suggestions

In an advanced database design class, students used NORMA for the first time to do several data modeling assignments. One of the graded requirements was to write a comprehensive feedback memo directed primarily to the developers of the data modeling tool. The memo was to be broken down into good points, bad points, problems, and suggestions for improvement or enhancement. This provides a unique opportunity to gather substantial feedback from users, since the students are highly motivated to use the tool to complete each assignment, working through any problems or frustrations they faced. Giving up was not an option. This paper provides a summary report of the experiences and suggestions as captured in the feedback memos. Several suggestions would be relevant for other fact-oriented design tools. Overall, students really liked using the tool, finding it to be reasonably intuitive and easy to use. Data model verbalization was the most frequently mentioned benefit. The major problems related to a lack of good documentation, the convoluted and difficult process of generating a database (DDL script), and the lack of adequate data model abstraction mechanisms.

An analysis of the data representation constructs of the ANSI NDL and SQL standards

Abstract This paper carefully examines the data structuring concepts underlying the two ANSI standards for data languages: the Network Data Language (NDL) adopted in 1986, and the Structured Query Language (SQL) adopted in 1986, its 1989 addenda with some integrity constraints, and the more continuing, advanced developments of SQL2 as of 1988 (not yet adopted). Using an initial presentation of semantic data modeling constructs, the data structuring and definition (not data manipulation) facilities of the two languages are systematically compared. This is done by looking at the surface semantics as reflected in the BNF syntax, then by looking at the underlying semantics of the two languages. The comparison reveals what is in both languages, in one but not the other, and what is in neither language. Given such a comparison, the relative strengths and weaknesses of the languages can be evaluated.

Summary of CODASYL report on “selection and acquisition of data base management systems”: CODASYL system committee

This panel will discuss the latest in a series of reports on data base management systems. Of special interest is the attempt to provide a systematic taxonomy for user needs and a means to relate them to the taxonomy of system capabilities developed in prior reports.