For more information about DEAR, see the IEA Team's website.

Training courses on DEAR are available--contact the IEA Team:

• Colleen Coggins, Chief Architect
• Suzanne Acar, Data Architect
• Michael McGreer, Technology Architect
• Carl Huls, Indian Trust Architect
• Diane Reeves, Business Architect

DEAR and the Wizard

DEAR

There are many analogies for DEAR; a switchyard sorting and organizing data, a bridge across islands of data, a data warehouse. It is a tool for collecting DOI-wide data in one place, so data is easier to find and different types of data are easy to compare. DEAR contains a tremendous amount of information about systems owned by DOI and its bureaus. For a full description of DEAR, see the IEA team website.

Not part of the wizard

For convenience, this tutorial includes instructions for entering C&A (certification and accreditation) information, deployments, and for designating a system as an enclave. The rest of the tutorial pages introduce the system wizard.

The wizard

The wizard simplifies working with systems in DEAR. Everything you do in the wizard, you can also do in DEAR; the wizard just makes it easier. The wizard is useful for anyone who doesn't need to get deeply into DEAR, but just needs to look at, add, and edit systems or parts of systems.

The graphic shows how systems and parts of systems are related in DEAR, and how they map to the different reference models (Performance Reference Model, or PRM, Business Reference Model, or BRM, Service Component Reference Model, or SRM, and Technical Reference Model, or TRM), as the reference models are shown in the main page of the wizard.

What the wizard does

This version of the wizard lets you map systems or their parts, as shown in the above graphics, to the various levels of reference models. (In this version, the DRM is read-only.) For more information on reference models, see the IEA Team website or the FEAPMO site.

Monolithic systems

The wizard only shows systems that are monolithic--that is, there is one system, one subsystem, one subsystem component instance, and one component. For now, that covers 95% of Interior systems. As the enterprise architecture (EA) improves, components will be re-used, and fewer systems will be monolithic. Future versions of this wizard will be built to handle systems that aren't monolithic.

What is a "component instance"?

A component can be copied, or re-used, many times in many systems. It is all the same component, but each copy is called an instance, or instantiation. For example, a car windshield is a component, but the windshields in two particular cars are two instances of windshields. An example of a component in Interior is the weather APIs the FWS uses (the same ones the Weather Channel uses)--the same thing as, but a different instance from, what firefighters would use for weather.

Future

Plans for the future include changing the wizard to handle non-monolithic systems, as mentioned above. In Phase 3b, the wizard will allow mapping to the DRM and to primary BRM functions. Another specific change planned is to have a confirmation screen for implied mappings. In some cases, making a new mapping implies a change in other mappings; these are called implied mappings. So that the mapper can see the effects of a mapping before saving, a confirmation screen will appear before the save is final.