# Presentation: 003654

## DEAR 201

**Improving Investment Management**
- An advanced course on the DOI Enterprise Architecture Repository (DEAR)

## Course Topics

- What DEAR is
- What DEAR is for
- DEAR is central to EA
- The DEAR metamodel
- Parts of the metamodel
- Who benefits from DEAR
- Using DEAR
- Data modeling: IDEF0 and IDEF3
- Conclusion

## What DEAR Is

- Course Topic 1
- Review (from the DEAR 101 course) of the DOI Enterprise Architecture Repository.

## What DEAR Is

- Without DEAR: You don’t know where the business value is; you have to dig up everything.

- With DEAR:  Less work, less disturbance, more result.  You dig only where there’s value.

- A tool to help you manage IT investments for the best value.

- DOI Enterprise Architecture Repository

## What DEAR Is

- Improves IT decisions by linking data on Interior’s
- Business objectives
- IT systems
- Technology standards
- Like a combination of graphics software and database software
- Lets you use text and diagrams together
- Used for storing data
- For bureaus: bureau-level data
- For Interior:
- Integrates the data tracked at the bureau level
- Includes significant bureau investments and critical systems
- Relates bureau-level data to Interior objectives and goals
- For enterprise architecture (EA): all architecture-related models, data, and artifacts
- Reporting tool: gives decision-makers critical information for analyzing architecture
- Source-of-record for architecture information on the systems tracked by Interior or bureaus

## What DEAR Is

- Inputs:
- Old stores of data for Interior and bureaus
- All the related information that used to be isolated in unconnected databases
- New data, that’s being collected right now
- Models
- Data models
- Process models
- Enterprise system information
- Federal architecture guidance
- Technical Reference Model (TRM)
- Business Reference Model (BRM)
- Performance measure
- Data on Interior’s
- Strategic goals, objectives, planned outcomes and measures
- Systems and IT investments
- Endorsed products and standards

## What DEAR Is

- Outputs:
- Reports on what processes, equipment, software, data, etc. Interior owns, and where it all is
- Models showing how well Interior fits the federal architecture framework
- Models showing how well Interior meets its own standards
- Reports suggesting where to find cost savings
- Reports showing gaps where we may need new IT systems
- Reports showing overlaps where we need to streamline the IT portfolios
- Reports showing where systems need to talk and don’t
- In general, DEAR maps relationships between the data so it can be analyzed.  The analysis drives Interior’s IT investments.
- Users:
- People who collect and input architecture data
- People who analyze architecture data
- People who use this information for IT decisions

## What DEAR Is

**DEAR Is Central to EA**
- DEAR standardizes data so that it is available for a variety of uses
- EA will not work without this commonality
- DEAR also holds the standards to evaluate architecture
- EA target models are built in DEAR
- DEAR is itself an EA data warehouse
- Combines information from many databases (such as ITIPS) into one store of Interior working data
- Interior EA source-of-record
- DEAR reports
- show gaps and redundancies
- track progress toward target

## What DEAR Is

**DEAR Is Central to EA**

## What DEAR Is For

- Course Topic 2
- How DEAR is valuable to the Interior.

## What DEAR Is For

| EA Phase | EA task | How DEAR is used |
| --- | --- | --- |
| 1 | Envision the future architecture | Build the architecture model in DEAR, showing how inputs relate to outputs |
| 2 | Determine scope, collect data | DEAR models show the scope; DEAR holds the data |
| 3 | Align Interior architecture with federal architecture | Query DEAR’s models and analyses to compare with federal models |
| 4 | Build modernization blueprints, at tactical and strategic levels | Use DEAR’s information to generate modernization blueprints |

## What DEAR Is For

- The work from phases 1 through 3 all leads up to phase 4: **Modernization Blueprints**
- There are two modernization blueprints, produced and managed in parallel, using DEAR
- Tactical = short-term; what we can get a return on right now
- Strategic = long-term; a broader view on saving and improving
**Tactical** modernization blueprint assists these decisions:
- O&M
- Project management
**Strategic** modernization blueprint assists these decisions:
- Investment proposals
- Business cases

## What DEAR Is For

## What DEAR Is For

**How to use a ****Tactical**** Modernization Blueprint**
- The blueprint shows managers
- Best candidates for tactical improvements
- Estimated time/money involved for each
- Models of architecture: as it now is, and as it should be
- Dependencies
- Managers can then
- Define and manage a baseline
- Set improvement targets
- Identify, select, and propose improvements
- Analysts use DEAR’s information to create a Tactical Modernization Blueprint Sequencing Plan
- Shows start and finish dates of events
- Shows which events depend on others

## What DEAR Is For

**How to use a ****Strategic**** Modernization Blueprint**
- Supports
- Mission goals
- Tactical plans
- What phase of investment each system is in
- Systems that overlap (candidates for cost savings)
- Relationships between systems and initiatives (such as e-government)
- Federal guidance on architecture and e-government
- DEAR is used to derive a Strategic Modernization Blueprint Sequencing Plan
- Road map to a more cost-effective architecture
- Plan for retiring and re-engineering systems
- Shows which investment proposals are most urgently needed for the future architecture

## What DEAR Is For

**Value of modernization blueprints from DEAR**
- Tactical recommendations give managers something to use now, with today’s dollars
- Top-down effect: High-level managers can watch how results affect overall mission
- Bottom-up effect: Practical tool for middle managers’ wise spending
- Strategic recommendations give managers an overall business direction for their technology and line of business
- Top-down effect: Practical tool for high-level managers to use in major decisions
- Bottom-up effect: Big-picture view for middle managers to show where business is headed

## The DEAR Metamodel

- Course Topic 3
- How DEAR is designed.

## The DEAR Metamodel

- Database schema for all DEAR data elements
- Also holds data element attributes
- Map of where to put things in DEAR
- Describes how the organization is described

- Metamodel is to DEAR as an outline is to a white paper
- Tool to organize information
- First step in planning
- Reviewed and improved with each draft, or release, of DEAR
- Built through customization code called “userprops” (short for “user properties”)

## The DEAR Metamodel

- User interface
- DEAR has a custom user interface
- Administrators can set which data different user types can get to
- Buttons on entry screen show possible selections
- Depends on
- Security needs
- Usability needs
- Editing rules

## Parts of the Metamodel

- Course Topic 4
- Description of the different domains in DEAR, and what each is used for.

## Parts of the Metamodel

- The entry screen is the interface between the user and the domains in DEAR, protecting the user from the full complexity of DEAR.
- Clicking on one of the buttons filters what the user sees.

## Parts of the Metamodel

**DEAR has 8 domains**

- 5 FEA models +
- 3 sub-architectures

- PRM = Performance Reference Model
- BRM = Business Reference Model
- SRM = Service Component Reference Model
- TRM = Technical Reference Model
- DRM = Data Reference Model

## Parts of the Metamodel

- 5 domains are FEA models:
- PRM—strategy/goals/objectives that drive the architecture
- BRM—business functions/activities/processes
- SRM—service components, or capabilities
- TRM—technology that performs the services, and standards
- DRM—data standards and models used by the services

## Parts of the Metamodel

- 3 domains are sub-architectures—other ways to look at the architecture
- Investment Architecture—investment information (pending)
- System Architecture—systems and their building blocks
- Deployment Architecture—where things are

- Note: ABC work activities are separate but associated with the PRM.

## Parts of the Metamodel

- Contains pieces of Interior’s Strategic Plan
- Goals, objectives, outcome measures
- Linked to the ABC work activities (which define work performed) by intermediate outcomes (which define strategic objectives supported)
- Work activities **must **be linked to goals.  DEAR is the only system of its kind to show that link
- Linked to the Investment Architecture—investments must support PRM goals from the Strategic Plan

- PRM:  Strategy/goals/objectives that drive the architecture

## Parts of the Metamodel

- Linked to the BRM through the ABC work activities.
- Example: If the number of oil permits is listed in the PRM, the PRM section of the metamodel may record
- Investments supporting oil permitting
- Systems supporting oil permits
- Oil permit lines of business
- How oil permitting is classified in the Interior-level PRM

- PRM: Strategy/goals/objectives that drive the architecture

## Parts of the Metamodel

- List of Interior Strategic Plan pieces that are both classified in the FEA PRM and linked to ABC work activities
- ABC work activity report
- All the investments and systems, listed by the goal they support
- All the ABC work activities, listed by their intermediate outcome goals (by Strategic Plan goals supported)
- All intermediate outcome goals that don’t support ABC work activities (may be the ones to eliminate)

- Potential PRM reports (examples)

## Parts of the Metamodel

- Maps Interior business to the FEA BRM
- Because the Interior BRM is done in DEAR, when the FEA BRM changes, this can also easily be changed.
- Also being in DEAR makes it easy to see where there are many financial systems doing the same function (you can see where it’s redundant)
- BRM is linked to the PRM so you can see what business is meeting which goals

- BRM:  Business functions/activities/processes

## Parts of the Metamodel

- Interior’s BRM is built on the pattern of the FEA BRM
- The BRM goes down to the level of ABC work activities
- Defining these low-level work activities and processes gives everyone in Interior common terms to describe Interior business
- Another benefit:  these low-level pieces of functions help show the best way to move your IT investments forward
- Data in the BRM section of the metamodel might include
- What investments support a work activity
- What sytems support a subfunction

- BRM: Business functions/activities/processes

## Parts of the Metamodel

- Printout of the BRM with a list showing which subfunctions and work activities support which investments and systems
- Investments and systems listed by line of business (such as recreation, law, fire)
- Investments and systems listed by FEA business area
- All systems with overlapping subfunctions (may be the ones to consolidate)

- Potential BRM reports (examples)

## Parts of the Metamodel

- Interior’s SRM is built on the pattern of the FEA SRM, but adds IT principles and best practices for Interior
- The SRM links to the BRM to show which BRM subfunction each SRM service supports.
- The SRM also has links to the TRM to show which technologies perform each service.

- SRM:  Service components, or capabilities

## Parts of the Metamodel

- List of service components
- Service components listed by system
- Systems listed by service component
- Printout of SRM, with links to principles and best practices
- How many different technologies or products satisfy a SRM capability

- Potential SRM reports (examples)

## Parts of the Metamodel

- Interior’s TRM is built on the pattern of the FEA TRM down to the third level (Technology Standards)
- Below the third level, the TRM adds details such as Technology Service Specifications for products, specifications, standards and technologies used by Interior and the bureaus

- TRM: Technology that performs the services, and standards

## Parts of the Metamodel

- Catalog of TRM products and their classifications
- TRM best practices and principles
- Report showing which technologies are being replaced
- Matrix showing how technologies depend on each other
- List of technology products
- List of which technology products support which SRM capabilities (service components)

- Potential TRM reports (examples)

## Parts of the Metamodel

- FEA DRM is not formally released: Interior’s DRM is built on the best FEA DRM information available
- The DRM includes
- Logical data models
- Conceptual data models
- Data categories (groups of data entities, also known as data subject areas)

- DRM:  Data standards and models used by the services

## Parts of the Metamodel

- Physical ERDs / IDEF1x  (graphic representations of data, their relationships to each other, and their properties)
- Logical ERDs / IDEF1x
- Conceptual ERDs / IDEF1x
- List of data subject areas
- Matrixes showing create-read-update-delete (CRUD) connections
- List of which data products support which systems

- Potential DRM reports (examples)

## Parts of the Metamodel (Future)

- Project or investment information about the system
- Allows investments and systems to be compared:
- Where are they in the investment cycle
- How are they funded
- Not the system of record for investment data
- DEAR lets you analyze the data

- Investment Architecture:  Investment information

## Parts of the Metamodel

- Template printout (Word document with all the PRM, BRM, SRM, TRM, and DRM information filled in.)  Useful in starting an investment after going through business process re-engineering (BPR) Lab
- List of all the investments modeled in DEAR, together with information previously stored in separate databases
- Investment requests listed by line of business

- Potential investment reports (examples)

## Parts of the Metamodel

- Closely related to investment architecture
- Shows how these fit together:
- Systems
- Subsystems
- System components
- Describes these things about system components:
- Services they perform (how they fit the SRM)
- Technology they use (TRM)
- Data they use (DRM)
- What business they support (BRM)
- What goals they support (PRM)
- Has C&A information to classify systems by whether they are certified and accredited (C&A status)

- System Architecture:  Systems and their building blocks

## Parts of the Metamodel

- Information about the system and its links to other architecture domains (PRM, BRM, SRM, TRM, DRM, investment, and deployment)
- Information on how major systems exchange their information
- List of technology products each system uses
- List of each system’s capabilities (service components)
- Report listing systems by
- (Future) Phase in the investment cycle
- C&A (certification and accreditation) classification
- Line of business

- Potential system reports (examples)

## Parts of the Metamodel

- Shows systems’ physical location and where their processing happens (not necessarily the same place)
- Tool for deciding whether systems could be concentrated or moved

- Deployment Architecture:  Where things are

## Parts of the Metamodel

- List of systems and system components by location
- Affinity reports that highlight location of similar systems (shows which systems could be consolidated for the most savings)

- Potential deployment reports (examples)

## Who Benefits From DEAR

- Course Topic 5
- Who gets what from DEAR.

## Who Benefits From DEAR

| This type of stakeholder... | Is in this position... | And DEAR helps them with... |
| --- | --- | --- |
| Executive | OMB, ITMC, MIT, Agency Head, IRB, OCIO | Vision, guidance, direction |
| Functional | Agency Sponsor, Project Sponsor, Functional Managers, Program Managers, IBAT | Requirements, portfolio funding requests, acceptance |
| Execution-Level | Project Managers, System Managers, DEAR IPT | Life-cycle information |
| Enterprise/Cross-Cutting | Strategic Planners, Investment Planners, IAWG, Security Managers, A-130 Managers | Strategies, plans, integrated views, standards, oversight |

## Using DEAR

- Course Topic 6
- Important concepts about DEAR which you will need to understand to use it.

## Using DEAR

- Subtopics
- Encyclopedia
- Data input (collecting data)
- Data analysis
- Data output (creating reports)
- Features

## Using DEAR

**Encyclopedia**
- The data repository underlying DEAR
- Every bureau has a copy of the encyclopedia, used and edited within that bureau
- “The” encyclopedia is the departmental Production encyclopedia which receives updates from the bureaus
- Stable database for information storage
- Holds all the components that capture the model’s meaning
- Diagrams, symbols, definitions
- Each encyclopedia component has information in properties or fields about the thing being modeled

## Using DEAR

**Encyclopedia**
- Structure is laid out by the DEAR metamodel
- Only privileged users can change the metamodel
- One master encyclopedia—the department-level Production encyclopedia
- Not directly editable
- Updated from bureau-level encyclopedias
- Holds a stable copy of all current information
- Used for publishing Interior reports

## Using DEAR

**Encyclopedia**
**Why there is a master encyclopedia**
**Problem**:
- DEAR can be useful to bureaus
- Bureaus need control over their own systems
- Interior needs to be able to track systems that cut across bureaus and support the investment process
**Possibilities**:
- One encyclopedia, many users—department and all bureaus use the same encyclopedia
- Too much information shared
- Many encyclopedias, one user for each—department and bureaus disconnected
- Too little information shared

## Using DEAR

**Encyclopedia**
**Why there is a master encyclopedia**
**Solution**: Interior has main encyclopedia, each bureau has a copy
- Bureaus can change any part of their own content
- Bureau copies periodically get merged with the Interior encyclopedia
- Only information specific to the bureau gets merged; no bureau can merge up a change to another bureau
- Interior will not change bureau-specific information
- Metamodel may be extended, but not changed, so the encyclopedias stay compatible for merges
- All department-level reports come from the department-level encyclopedia
**Result**: Culture of bureaus is respected while still meeting needs of the department.  Bureaus have flexibility, but Interior can still track information on cross-bureau systems

## Using DEAR

**Encyclopedia**
**Caution:**** Issues with managing Interior and bureau encyclopedias**
- Out-of-date interface descriptions
- Same name used for different things
- Different names used for same thing
- Harder to notice conflicts within an encyclopedia
- More encyclopedias means more administrator time
- Updates in one bureau may occasionally affect other bureaus at the next merge

## Using DEAR

**Data Input**
- Normal method: use the menu and browsers to create or update symbols and definitions
- Other methods:
- Import definitions
- Reverse-engineer data *
- Reverse-generate code *
- Define a macro to import data
- Use XML Metadata Interchange (XMI)

- * Reverse-engineered models are made by taking code and making a model out of it, instead of writing code from a model.
- A relational database can be reverse-engineered into a physical data model that shows the tables and their relationships in a diagram.
- Class definitions in C++ and Java can be reverse-engineered into a UML Class Diagram.

## Using DEAR

**Data Analysis**
- DEAR shows relationships between model data definition types, using matrixes
- If there is no relationship, the box where two types intersect will be blank
- If there is a relationship, the box may just have an X or may have a paragraph describing the relationship.

## Using DEAR

**Data Output**
- DEAR is not just for storage; all the intellectual resources stored in the models need to be distributed to the people who make decisions, through reports
- Reports can be produced in many forms for a wide audience:
- Simple query reports
- DEAR-generated documents
- HTML pages
- Database schemas
- DEAR-generated code
- Data exported to simulation tools

## Using DEAR

**Data Output**
- Query language is used to get report information from the encyclopedia
- Many report templates (Standard Report files) to use or modify
- Send report directly to printer, or format it with Word for more clarity
- Diagrams can be published in HTML
- Symbols and definitions can be linked to explanatory pages for readers’ convenience

## Using DEAR

**Features**
- Supports many users at the same time
- Inactive users get kicked off after a set period so someone else can use the license
- Check-out feature
- Changeable to the one who checked it out
- “Read-only” to everyone else
- Freeze feature
- Unchangeable until unfrozen
- “Read-only” to **everyone**
- Only administrator can freeze or unfreeze
- Supports many
- Modeling techniques
- Types of databases
- Programming languages

## Using DEAR

| For this kind of work | DEAR gives you these tools |
| --- | --- |
| Business Process Re-engineering  (BPR) | IDEF0 function modeling, IDEF3 process flows, IDEF1X data models, *BPMN (support for v0.9 of BPMN, generation of BPML and BPEL4WS)  |
| Structured systems analysis and design  | Gane and Sarson, Ward/Mellor, SSADM, Yourdon/DeMarco.  |
| Data modeling  | Entity relation models, physical data models.  |
| Object Oriented Analysis & Design  | UML, OMT (Coad/Yourdon, Booch 94, Shlaer/Mellor) |
| Extensible Markup Language (XML) | XML diagram – generation of BizTalk and DTD  |
| Data modeling database support  | Reverse data engineering into, and schema generation out of, physical data models, using AS400, Oracle, SQL Server, dBASE, OS/2, SYBASE10, DB2, Paradox, Teradata, INFORMIX, Progress, WATCOM, Ingres, RDB, XDB, InterBase, SQLBase, Microsoft Access, SQL Anywhere |
| Object-Oriented (OO) language support | Support for generating languages from OO diagrams (includes reverse code engineering options for C++ and Java).  Languages include C++, Java, CORBA, Visual Basic |
| Documentation | Supports web publishing with HTML, also links to Microsoft Word 97 and 2000 |

**DEAR Features**

## Data Modeling: IDEF0 and IDEF3

- Course Topic 7
- A brief description of the two main types of data modeling.

## Data Modeling: IDEF0 and IDEF3

**Brief introduction to the data modeling diagrams used in DEAR**
**DEAR uses IDEF diagrams, especially IDEF0 and IDEF3 diagrams**
- Boxes and arrows make a model as words make a story
- Easy to expand into deeper detail
- Widely used in government, industry, and commerce
- Way to communicate about processes, to build consensus
- Shows up no-value processes
- Shows up processes with lots of improvement potential
- Used for activity modeling; complements data modeling
**IDEF0**
- Shows main inputs and outputs
- Shows what you need to do the activity
- Shows forces controlling the activity
- Simple picture of an activity, showing just **i**nputs, **o**utputs, **c**ontrols, and **m**echanisms (ICOMs)
- Answers question “What do we do?” (or at least “What should we be doing?”)

## Data Modeling: IDEF0 and IDEF3

**IDEF3**
- Describes a process
- Includes time information
- Shows the order in which things happen
- Shows what causes what
- Shows how decisions are made and how the decisions affect shared data
- Helps analyze trade-offs of system design changes
- Good way to record data on how systems work after interviewing system experts
**For more on IDEF modeling, see **_[http://www.idef.com](http://www.idef.com/)_

## Conclusion

- Course Topic 8
- Summary and references.

## Conclusion

**Now**:  We’re using DEAR to collect data to model the architecture we have now.
**Next**:  We will analyze the data in DEAR and find the best direction to move forward
**Finally**:  We will use DEAR to create the modernization blueprint that will get Interior’s key business areas to the architecture we want to have

## Conclusion

**Remember**
- DEAR is a method of communication; a way for many contributors to come to a shared understanding
- DEAR has the potential to give decision-makers vital information at the time they need it
- DEAR makes life easier for EA modelers
- But...
**The ultimate purpose of DEAR is not to build successful models, but a successful Interior!**

## For More Information: Contacts and References

- Colleen Coggins—Interior Chief Architect,      (202)208-5911, _[Colleen_Coggins@ios.doi.gov](mailto:Colleen_Coggins@ios.doi.gov)_
- Jim Johnson—Interior Business Architecture (IBA) Contract Team Lead, (202) 452-7733, _[James_Johnson@blm.gov](mailto:James_Johnson@blm.gov)_
- Jim Barrett—IBA Contract Technical Lead, (303) 236-5353, _[James_Barrett@blm.gov](mailto:James_Barrett@blm.gov)_
- Draft DEAR metamodel: _[http://](http://www.doi.gov/ocio/architecture/dear/)__[www.doi.gov/ocio/architecture/dear](http://www.doi.gov/ocio/architecture/dear/)__[/](http://www.doi.gov/ocio/architecture/dear/)_
- Popkin website: _[http://](http://www.popkin.com/)__[www.popkin.com](http://www.popkin.com/)_

## Document Abstract

| Doc Status | Rev. Date | Author/Editor | Description of edit | Filename/lineage |
| --- | --- | --- | --- | --- |
| WIP | 11/07/03 | Karen Tallentire | Made Colleen’s changes from draft | S:\Dear\IBA\WIP\Communications\Architecture Curriculum finals (sent to Colleen)\DEAR 201 |
|  |  |  |  |  |

| Key Words: | Architecture, curriculum, DEAR 201 | FEAF Area:
Subject Function Code: | M
1230 | Contract #:  NBD020221
Task Number:  8 |
| --- | --- | --- | --- | --- |
| Part of the Architecture Curriculum for the Communications task |  |  |  |  |

**Revision History**