Data Architecture: From Zen to Reality

Data Architecture: From Zen to Reality

by Charles Tupper

View All Available Formats & Editions

Data Architecture: From Zen to Reality provides an introduction to the basic principles of data architecture, focusing on the development and implementation of enterprise-level information architecture.
The book is organized into five sections. Section 1 discusses the data architecture and data design principles needed to reintroduce architecture into the business…  See more details below


Data Architecture: From Zen to Reality provides an introduction to the basic principles of data architecture, focusing on the development and implementation of enterprise-level information architecture.
The book is organized into five sections. Section 1 discusses the data architecture and data design principles needed to reintroduce architecture into the business and software development process. Section 2 deals with the business and organizational issues of modern businesses and how structured and architected approaches may help them remain flexible and responsive. Section 3 focuses on the software-application development process, defining tools, techniques, and methods that ensure repeatable results. Section 4 discusses the artifact results of the process and the ways to make output products more efficient in real-world environments. Section 5 covers specialty databases and the various issues that arise in the business data processing environment, including data warehousing, objects and objects relational databases, and distributed databases.
This book was written for people in business management involved with corporate data issues and information technology decisions. It is also a reference tool for those in a higher-level education process involved in data or information technology management.

    • Presents fundamental concepts of enterprise architecture with definitions and real-world applications and scenarios
    • Teaches data managers and planners about the challenges of building a data architecture roadmap, structuring the right team, and building a long term set of solutions
    • Includes the detail needed to illustrate how the fundamental principles are used in current business practice

    Read More

    Editorial Reviews

    From the Publisher

    I am extremely thrilled that Mr. Tupper has decided to write this book. This book would fill a void in knowledge and know-how in the area of data administration and architecture. Mr. Tupper built over the years an impressive expertise and authority on the subject of enterprise data architecture.

    Daniel Fitzpatrick, Principal Consultant, Nakama Consulting Group

    I see a wealth of information ranging from technical reference information to higher level concepts and principles. Overall a very comprehensive guide where some sections can be read in a flowing manner to enhance understanding of the topic and other sections can be flipped to/from to provide greater detail and context.

    Lynn Rivera, Consultant, LMR Consulting

    Product Details

    Elsevier Science
    Publication date:
    Sold by:
    Barnes & Noble
    NOOK Book
    File size:
    3 MB

    Read an Excerpt

    Data Architecture

    From Zen to Reality
    By Charles D. Tupper


    Copyright © 2011 Elsevier Inc.
    All right reserved.

    ISBN: 978-0-12-385127-7

    Chapter One


    Defining Architecture ar·chi·tect (är'kitekt') n. (Abbr. arch., archt.)

    1. One who designs and supervises the construction of buildings or other large structures.

    2. One who plans or devises: The United States is considered to be the chief architect of the economic recovery of the Middle East.

    The word "architect" is of Greek origin and is composed of two roots: arch and tect. Arch means "primary," "primitive," or "coming before," and tect means "make" or "come into being." Thus, when the two roots are combined to form the word "architectos," it can mean "coming before" + "come into being." Using these multiple meanings, we can figure out the definitions of architect and architecture. A good working definition of architecture would be "a primitive plan" or "a plan before construction." This definition captures the essence of it: Architecture is an analytical effort that is created prior to the occurrence of any real construction activity. It is the abstracted framework or outline that provides guidelines for the construction from the beginning to the end.

    The discussion of architecture is interesting both from the point of its expansive concepts to its detailed specificity at the point of physical implementation. The following is an excerpt from an Information Architecture course (that ultimately never came to fruition) that speaks to the concept requirements:

    The object of this course is to lead to an understanding and application of the principles of design—particularly architectural design. The fundamental purpose of architectural design is illuminated by the logic of the process of design: target, options, concepts, actions, and completion. Exploring the design process integrates both the physical and nonphysical requirements and influences; the measure of human processes and the collective events of many processes; the social and cultural influences operating in such processes; and the meaning of information extensions, directions, order, and closure. The importance of the relationship between human processes and the information environment is introduced with an emphasis upon construction of information models. Composition, especially the theory of wholes and parts, is examined in the light of structural reusability, continuity, and change—principles and conditions applicable either to a single business process or, in a much wider context, to the task of capturing an entire enterprise into its business environment.

    Architecture is an ancient skill that has been practiced by visionaries since the prehominids decided to create and build shelters to cope (interface) with the chaotic life patterns of their natural world. A primitive designer probably had the same level of respect in his tribe as the shaman (if they were not one in the same). As humanity evolved, these special individuals carried forward the inherent principles or patterns that had proven successful in their evolution. Knowledge of structures and the patterns and mechanisms of building was accumulated and passed on—and on and on. This process of handing down skills and patterns hastened the development of communication.

    What would happen if a primitive hut builder created a very radical design? Most likely, no one would accept the structure unless the designer communicated the advantages of the new design to the tribe. Additionally, when the primitive designer/ builder started his effort, he just had to create a few huts. As tribal growth occurred, there was much more work to design and lay out the groundwork for many huts and meeting places in addition to creating the huts.

    These habitation structures had to be made to interface with and take advantage of the natural background and environment. The designer/builder's input to the site selection of camping grounds became critical. He became an integral asset to the tribe's survival. Just as the designer/builder had to keep learning to construct and maintain the structures out of local materials, he had to accumulate and retain the knowledge he had gained to be passed on to future primitive architects.

    All along the way there was a continual implementation of what knowledge had been accumulated up to that point, and, more important, that knowledge was made public. It would not be kept private or restricted because the tribe's livelihood rested on the designer/builder's integrity. The design had to be understood and accepted by the entire tribe and had to be depended on for the tribe's survival. At each level appropriate knowledge was imparted to those concerned.

    The individuals in the tribe were educated in the best techniques. This skill sharing allowed more growth and stability. Implementation had provided a new plateau to build on. As the tribes were educated, all of the members learned the skills necessary to build and keep the structure intact. Adaptations had to be made for the differences in environment. Some of the designs had to be ultimately flexible, while others had to be extremely stable and less flexible. Evolution of designs became more complex and more important to the survival of the whole tribe. The adaptability of the designs became an important feature of the designs and was therefore included in the saved information. These codes of construction and site selection became, after a millennium, building codes. This body of principles and logic used in designing for those codes would ultimately be called "architecture."

    These individuals were astute at recognizing patterns in the real world around them. The strength of a wood and grass wattle hut wasn't as great as a cave's, but it served the same purpose: it kept them safe from the elements. After all, caves wouldn't be available everywhere they went, so such natural shelters were at a premium and often had to be competed for. Primitive hut designers realized that a hut could be built in the same design as a cave—tall in the middle and low at the sides for storage room and sleeping. Fire could be put at the mouth of the hut or outside with the heat reflected in, or, better yet, heated stones from the fire could be rolled into the hut to radiate warmth.

    Situating the construction on a higher foundation isolated it from the ravages of heavy rains. Building it on the sheltered side of a hill kept cold winter blasts from chilling the inhabitants and also protected the fire. They also learned to build these shelters close to water and plentiful sources of game. In essence they adapted the housing to the environment, being respectful of it and integrating the structure with as many natural principles as possible.

    Pattern recognition and pattern use are embedded in the principles of early humankind's existence, so the use of architectural principles is quite ancient. While it may have had different names through the ages, and its practitioners had different labels, the principles are the same: Plan before you build, and design with the user in mind. Integrate the plan into the environment where it will be situated.

    These are the same principles that prompted the first individual of vision to step out of the cave and find a way to bring it along with him as he moved around to follow food. He had the responsibility of defining a working structure and method, showing and convincing others that the structure and method were feasible, and, finally, ensuring that the structure and method would be reusable in spite of the local environmental conditions. All of these concepts and his ability to perceive the patterns where they could best be implemented led to humankind's success and adaptation.

    Obviously, we no longer have to worry about building safe habitats for cave dwellers. They already did that themselves. But we learned things along the way. And the primitive art and science of architecture evolved from simple tribal housing to providing a place for the very essence of cultures. Architecture and its principles have burgeoned and expanded to include all parts of the fabric of today's society.

    Design Problems

    The design process is unique, and it is easy to see that the goal of the design process is a solution. So this all seems very simple, but unfortunately, this is not the case. As we have already discussed, the real crux of design is defining the problem in the context in which it must be resolved. The contextual analysis is the hard part. In a true design process, the work area must first be defined and delineated from the context it is in. Whether it is a problem or opportunity, it needs to be separated from the matrix in which it exists. If the matrix or context is dynamic, however, the problem area is dynamic as well.

    The design solution ends up being a balancing of the solution to the forces defining the problem's boundaries. It becomes an integral fit and, if constructed properly, will adjust to the context in which it exists. Take a simple problem like building a mechanical device. The forces in play are economy (or the cost of the components), performance (both of the product itself and of the ability to create the product), simplicity (the more components involved, the more complex the building process), and interfit (assembling the components to create the product).

    Material handling studies indicate that the fewer the types of material used, the faster assembly will be, so simplicity is important. This will conflict with the performance force because we know that using the best material for each part will make the product last longer. The performance may affect the interfit force vector, since the materials chosen for the best performance may require more effort to assemble than simpler, less functional materials. All of these force vectors affect economy because they all impact the price of the item in some way. It is the balancing of these forces that determines the solution. Figure 1.1 shows how the resolution can be reached. By assigning a positive or negative quality to the interaction among these forces, we can come up with a simple solution depending on the product's purpose.

    We have chosen economy as our driving force, so we can see that a positive relationship exists between simplicity and economy. Based on this, we can apply whatever performance and complexity choices we want as long as they remain in that quadrant. If assembly was primary and simplicity was secondary, then balancing would be in that quadrant, with the resulting solution not being as economical as might be desired.

    While this is an extremely simple visual display of a complex set of interactions, in the end it is the balancing of those dynamic forces at work in the context of the problem/solution area that will provide the optimum solution. Simply put, the problem area cannot be removed from its context because it is a part of the context of the whole and is defined by the dynamic forces working on it in that context. How, then, are problems addressed in an architectural manner? The answer is, by using patterns and pattern interactions.


    Excerpted from Data Architecture by Charles D. Tupper Copyright © 2011 by Elsevier Inc.. Excerpted by permission of MORGAN KAUFMANN. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
    Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

    Read More

    Customer Reviews

    Average Review:

    Write a Review

    and post it to your social network


    Most Helpful Customer Reviews

    See all customer reviews >