When you first think about a custom-built house, you consider many things like the location of the lot and positioning on the lot, the style, approximate size, types of features, and even how you will move within and outside it.  You make some sketches to get an idea of how it will look, to help envision yourself in it, and to consider alternatives.

When you first think about a computer system you also consider many things.  First off, you should think about the business need for it - just because you or your technical people can build it doesn't mean you really need it.  There must be a business reason for it.  Once you understand the business need, you can consider how the system will help your business.  Often this involves making diagrams about workflow, data flow, processes and activities ... this is business modeling.  It helps you understand what the system will do and it helps you consider alternatives.  These models are essential to develop the functional requirements for your system.

You take the sketches of your house and building lot to an architect.  They prepare a set of more formalized illustrations that show various views of your vision.  You are pleased that the architects drawings are allot better than your sketches - they are professionals and you expect better drawings than you can make.  These drawings may illustrate different building materials, like brick versus clapboard sidings, and may show the house in various positions on your lot and with various landscape features.  This helps you better consider alternatives and also helps the architect communicate a more formal view of what you desire.

The systems architect similarly prepares diagrams about how the system is envisioned to operate.  There are a variety of diagrams depending on the design approach and system paradigm.  There is often a more formal activity model or flowchart that illustrates how the system will function, and there is a very general data model that identifies the key data needed by the system to meet your business needs.  These are the conceptual models - particularly the conceptual data model.  These help you consider alternatives and zero in on the system function and features.  You are pleased that these models have a better appearance and convey what you need in technical terms - the system architect is, afterall, the IT professional and brings skills and a technical understanding that you as a businessman do not have.

After the architect reviews these conceptual drawings with you, and you agree that these represent the house you envision, they prepare a set of blueprints.  These blueprints translate the artistic view of your house to a design document that a construction crew can use to build a structure that makes your vision tangible.  Blueprints present often hidden design features, such as foundation specifications, and electrical and plumbing courses, that are not considered in the design drawings because these would be excessive detail beyond the needs of the drawings.

Likewise, the system architect creates logical data model that is the blueprint of the data system.  The logical data model is based on the and often directly derived from the conceptual data model.  This logical data model is a technology independent view of the database - it can be implemented in any relational database management system.  In fact its implementations in dissimilar systems like Oracle and SQL Server will not appear the same, but have the same capabilities because the same logical data model is used.

Every architect, contractor and builder is constrained by standards and best practices represented by building codes.  The local construction codes tell the architect and builder what can be built and how it can be built.  These building codes are equivalent to the organization's data standards and the role of the building inspector is performed by the organization's IT quality assurance processes.

With blueprints, design specs, and code requirements in place, the builder determines what materials are needed and arranges to have these delivered.  The data dictionary is analogous to the builder's bill of materials.

Likewise, an implementation guide shows the systems developer how to use the logical data model to build the data system.

Where the builder will paint the walls in the color scheme the buyer desires, the database developer will "color" the data system to best meet the user's desires.