This can happen if your computer was offline from the local network when you started your DEAR session, because printers are normally on the local network. You may get this error while generating reports, even if you aren’t trying to print them, because System Architect requires a printer to be available when reports are generated.
You will need to log out of DEAR, but you don’t have to restart your machine. Make sure you are online when you log back in. (If you are offline, an icon in the lower right-hand corner of the screen will tell you so.) If you keep having problems with going offline, talk to your local helpdesk.
Your audit ID is the first seven characters of your username for getting into DEAR or Citrix. (If your username is jjohnson, your audit ID would be jjohnso.) The audit ID gets attached to all changes you make in DEAR or a BEAR, so if there are questions about a change, it can be traced. Whenever you log in, the system checks your audit ID against the first seven characters of your username. If they don’t match, the system changes your audit ID and makes you log in again.
The systems in DEAR were loaded from many sources. Domain-specific inventories and other past efforts were combined to get the inventory in DEAR. Source lists included:
Security (two versions of the C&A system lists)
Investment (ITIPS, Exhibit 300s, Exhibit 53, and a database from the Office of the Budget (POB))
Lists from specific lines of business (LOBs), including Recreation, Fire, Financial Management, and Law Enforcement, as well as the Trust architecture
Other efforts, such as the ITMR list from 2000
The lists were combined and reviewed with the A-130 PMO at the OCIO. The entire list of over eight hundred systems was tagged with a unique identifier for each system (the format is: department_bureau/office_#). The philosophy has been, when in doubt, add the system, because it is better to subtract systems when the bureaus validate the lists, than to overlook a system that should be in DEAR. Certain categories of systems, the DOI-tracked ones, need to be in DEAR. When validating the DOI list of systems, each bureau is asked to check that the bureau's inventory includes all systems that fall into the following categories:
Major applications
General support systems
Systems associated with an Exhibit 300 or 300-1
Financial management systems
If a system doesn't fit any of these categories, it can be removed. Mark "D" for "delete" in the first column for this system, then in the "Comments" column, write "This system does not fall into a DOI-tracked category." The A-130 will review the request. If a system is marked "D" but the comments are not updated, the system will not be deleted, to keep systems from being accidentally deleted during validation.
Certain kinds of systems need to be listed in DEAR. See the DOI-tracked categories listed in Why is this system in DEAR?) If a system is in one of these categories, but isn't listed in DEAR, and your bureau is the managing partner, please add the system, with comments explaining the situation, to the bottom of the list. There may be many, even hundreds, of systems missing from the list, so please don't assume a system in your bureau inventory was intentionally left off the list. But do double-check that it's really in a DOI-tracked category.
DOI has extended the OMB's BRM by mapping the ABC work activities to the subfunctions in the OMB BRM. This mapping hasn’t been approved by the IBAT yet. When it is, bureaus will be asked to map their systems to the BRM. Until then, bureaus should leave existing mappings alone, or risk having to re-map after the IBAT makes its decision.
DOI has extended the OMB's PRM by mapping it to the Strategic Plan. This mapping hasn't been approved yet. When it is, bureaus will be asked to map their systems to the PRM. Until then, bureaus should leave existing mappings alone, or risk having to re-map later.
There were 10 major sources of lists of systems (see Why is this system in DEAR?), and they didn’t all use the same names. When two very similar names appeared, both names were left in until they could be validated. If you can tell that a system is duplicated, mark one of the systems to be deleted ("D" in the first colum), and in the comments say "REMOVE - Duplicate of System Name [inventory ID]". That way, the relationships and attributes of the deleted entry will be copied over to the remaining system.
Some links (PRM, BRM, SRM, or TRM) were made from source information in previous data calls, or from other data sources (System Security Plans, ITIPS, etc.) Don’t change them yet. After the reference model mappings are approved (see Why aren’t we linking to the BRM yet? and Why aren’t we linking to the PRM yet?), the bureaus will be asked to map their systems to the reference models. At that time, you can use the DEAR wizard to add and remove links.
When DEAR was first populated, some data, such as system platform information, was in a hard-to-import format, so you don’t need to do any TRM mappings until the inventory is validated. It won’t be until the next phase of data validation that the bureaus will map platform information to the TRM. But you can prepare for it now by asking your BITSM for system security documentation (system security plans, AVGs, etc.) that would show the relationships you will later need to map. Once the inventory is validated, DEAR will be the official data source for mapping information.
When DEAR was first populated, some data, such as system platform information, was in a hard-to-import format. Once this information is all entered in DEAR, DEAR will be the official data source for systems’ security status. Meanwhile, during this first phase of data collection, bureaus should go ahead and enter this information while validating their own inventory of systems.
DOI is required to collect privacy information about its application systems, and bureaus should fill in the information during this first phase of validating the system inventory. (Use the Privacy Impact Assessment Document if available; if not, the five privacy questions can also be found in an Exhibit 300.) To cut down on data calls from OCIO, we collected critical information on application systems using an integrated product team (IPT). DEAR will be the official data source for the data DOI is required to collect about its application systems.
This is much the same issue as Why do some systems have two or more names?. A system that appeared in more than one source list (for instance, if it appeared in both the Exhibit 53 and ITMR) might have a different name in each list. If it was very different, it became a duplicate. If it was only a little different, we deleted the extra entry, but the name of the one left may be wrong. Please check that the name used is the official, current, or popular name for that system. When you update a name, please add in the comments, "NAME UPDATED - ..."
Most inventory IDs look like DOI_MMS_4, DOI_USGS_3, DOI_BLM_57, etc. The ones that look like DOI_BLM_PENDING were added through the wizard tool, in the IEA's effort to create line of business portfolios for Fire, Law, Financial, and Recreation. A-130 and the OCIO requested that a system not be accepted until it is reviewed by A-130, and meanwhile it is marked as PENDING. These systems should be validated along with the accepted systems.
If it has an investment (300, 300-1, etc.) and can run as its own system, leave it as a system.
If it really should be a subsystem, mark it "D" for "Delete" in the first column, and in the comments say "System X is a sub-system of System Y and is funded by System Y's investment vehicle".
Yes. The way DEAR is set up now, the removed system stays in DEAR; the only thing that's really removed is its row in the DOI-TRACKED-SYSTEM table. You can pull down any related data that has already been collected, but the system won't appear on inventory reports. This is actually how we track DOI-tracked systems and bureau systems in the same repository.
One sense in which "system" is used is something that has many systems or subsystems that it invests in. All these systems and subsystems are then considered subsystems of the "system" that invests in (re-deploys, re-engineers, etc.) them. Please put a note in the comments of anything which is only a system in this sense. The comment should be something like, "The Re-engineering Project is investing in the BPR for this system."
In Phase 1 of Round 1 of the validation process, there is a spreadsheet for entering this information. The spreadsheet data will be entered in DEAR, the BEARs updated, and then in Phase 2 and 3, you can use the wizard found in your BEAR encyclopedia (more details on this to come in Phase 2.)
This bug in the data has been already addressed in the master list. This field was not intended to be editable. To make changes in this field, enter a note about it in the Comments field. In the master list for Trust, all systems have been updated according to the C&A designation of being a Trust system.
This capability was not a requirement for Phase 1. The C&A team directs enclave updates, and that data has not been loaded yet. You can make a note in the Comments field for future reference; when the C&A enclave information is provided, your comment will be checked against it.
This information is not a requirement for the first round of Phase 1, but if you have the information, it will help a lot if you enter it as a separate activity. It will be loaded as soon as the data is checked for cleanliness and fit for the DEAR model. Please contact the Chief Architect to coordinate this effort.
The data collection originally focused on 200 systems falling into the Law, Fire, Financial, and Recreation lines of business, as well as any system with an Exhibit 300. Systems outside of these categories were added to the inventory but left as a skeleton.
If the source of information listed the wrong Managing Partner, the system obviously should not be part of your portfolio. This can be a particular problem for cross-agency or department-wide systems. Use the validation template to change the Managing Partner. Noting the problem in the Comment field will also help.
Only records with personal information are controlled by the Privacy Act. Records about businesses are not controlled by the Privacy Act, nor are records about individuals as they represent a business. Personal information stored for the purpose of providing a userid for the system is not controlled by the Privacy Act. Personal information is:
information on race, national or ethnic origin, religion, age, and marital or family status
information on educational, medical, psychiatric, psychological, criminal, financial, or employment history
anything assigned as identification to an individual, such as a number or a symbol
name, address, phone number, fingerprints, blood type, and DNA
completed privacy impact assessment--A yes/no indicator showing whether the system owner or system manager has developed a Privacy Impact Assessment. This indicator is needed for systems with information about individuals.
individuals doing business--A yes/no indicator showing whether the system maintains information on small business owners who interact with the Department.
personal privacy concerns--A yes/no indicator showing whether the system maintains information on individuals and may therefore have privacy concerns.
privacy act system of records--A yes/no indicator showing whether the system has information which can be retrieved by a name or other personal identifier (employee ID, SSN, etc.)
public information individuals--A yes/no indicator showing whether the system maintains information on non-DOI employees.
PIA is sometimes embedded as an appendix to the Exhibit 300. In Exhibit 300, Section I.F, Risk Inventory and Assessment (All Assets), there is a table in the "Area of Risk" column. Within that table, look at the row where the column value is "Privacy".
Not fully specified, and is not a solid source for privacy information. The best option is Section II.B, Security, but the text is usually verbose.
Personal Privacy Concerns
Section II.B.3: "How does the agency ensure the effective use of security controls and authentication tools to protect privacy for those systems that promote or permit public access?"
In Section A (or Section 1.2), question 1 asks, "Does this system contain any personal information about individuals?"
In Section F (or Section 1.6), question 4 asks, "What controls are in place to prevent the misuse (such as unauthorized browsing) of data by those having access?"
Privacy Act System of Record
In Section E (or Section 1.5), question 9 asks, "Under which Privacy Act systems of records notice does the system operate? Provide number and name."
Completed Privacy Impact Assessment
Section II.B.5: "If this is a new or significantly altered investment involving information in identifiable form collected from or about members of the public, has a Privacy Impact Assessment (PIA) for this investment been provided to OMB at PIA@omb.eop.gov with the investment’s unique investment identifier?"
If all sections of the PIA are answered, mark the PIA completed.
Public Information Individuals
Section II.B.4: "How does the agency ensure that the handling of personal information is consistent with relevant government-wide and agency policies?"
In Section B (or Section 1.2), question 1 asks "Does this system contain any personal information about individuals?"
Individuals Doing Business
In Section C (or Section 1.3, Data in the System), question 1 asks, "What categories of individuals are covered in the system?" Question 2 asks, "What are the sources of the information in the system?"
In Section D (or Section 1.4), question 3 asks, "Will the new data be placed in the individual's record?" Question 9 asks, "What kinds of reports can be produced on individuals? What will be the use of these reports? Who will have access to them?"
You can review the Exhibit 53, or contact the business case owner. But on June 13, 2003, the DOI released a comparison of 300s and 300-1s to 53s. This Excel file has the list of investments broken up by bureau and office, and by whether the investment has a 300 or a 300-1. The list shows the investment name and acronym on the Exhibit 53 and the UPI code on the Exhibit 300 or 300-1 (not necessarily the same.) This data was loaded into DEAR, but needs to be validated and updated--this report is 7 months old.
Usually, this is an issue with the network between you and NBC. You can check the network speed by going to the DEAR login page and clicking on "Test your bandwidth". You'll get a popup window which shows you the speed at which a test file loads. If that still doesn't explain the problem, contact the DEAR helpdesk at (303) 969-7777, 1 (888) 269-0310, or nbcden_itsc@nbc.gov.
Like any other new application, DEAR will sometimes crash. DEAR is set up to protect the data integrity through the crash. You can help improve DEAR's reliability by copying the SQL server error message and sending it (preferably electronically) to DEAR's helpdesk (nbcden_itsc@nbc.gov). They will use it to debug the problem.
Contact the DEAR helpdesk at (303) 969-7777, 1 (888) 269-0310, or nbcden_itsc@nbc.gov. If your account status is okay, they can unlock you immediately.
This can happen if the system is running a macro (such as a report or the System Wizard) while another window (such as a definition) is open. To close the window, just reopen the encyclopedia.
Support queries on systems across Interior's whole enterprise in emergency situations, such as the litigation orders shutting down Interior Internet access.
Help Interior find, by mapping to reference models, where systems overlap, so that Interior can reduce costs by consolidating, sharing, or retiring system components.
Prepare an Interior system inventory to use in creating modernization blueprints and Target Application Architectures (TAAs) across lines of business. These products will reduce costs and make processes more effective.
The validation started in February 2004, and is expected to last about 120 days. The three phases are shown in the diagram below. Phase 1 is light blue, Phase 2 is pink, Phase 3 is purple.
Phase 1 started in February 2004, and was scheduled to last 30 days. Its scope and level of effort are small compared to the overall validation. See diagram below.
Phase 2 started in late March, 2004, and is scheduled to last 45 days. Its scope and level of effort are large, the biggest part of the overall validation. See the pink boxes in the diagram below.
Phase 3 starts in early June, 2004, and is scheduled to last about 45 days. Its scope and level of effort are medium: a significant part of, but not the majority of, the overall validation. See the purple boxes in the diagram below.
In the four steps listed below, step 1 takes 5-10 minutes, steps 2 and 3 take 5-20 minutes each, and step 4 takes 15-30 minutes. OVerall, it will take 30-80 minutes per system. The validation will be shorter for those familiar with the reference models who are using a legacy system model. It will take longer for those unfamiliar with reference models who are using a tiered system mode.
Check Phase 1 spreadsheet updates.
Model the system appropriately.
If necessary, update the system architecture in the browser with the BEA team's help.
Relate the system components to reference models, using DEAR's wizard.
See the diagram below. A system is an organized assembly of resources and procedures, which are united and regulated by interaction or interdependence, to perform specific functions. An IT system is a collection of hardware, software, and documents that implements an IT solution to a problem, and describes that solution.
You can break a system into subsystems that use system component instances. These instances are the physical software that runs on hardware. These components specify the what the system component instances do. Or you can think of it the other way around: the system components are organized into subsystems, and the subsystems collaborate. The subsystem collaboration is what makes the system deliver the behavior you can see, the business solution for which the system was designed.
A system is the top-level organization for a solution. It is not directly deployed on the technology infrastructure. (That's why it's shown with a dotted line in the picture below.) It can have one subsystem, or many subsystems.
See the diagram below. A subsystem is a grouping of components within a system. It is the next level below the system level. A subsystem is a logical relationship for a group of components that is a major subset of what the system is and does. For example, if your system is a car, it would have a steering subsystem, an engine subsystem, and a passenger-holding subsystem. What a system does is the sum of all the things its subsystems do.
A subsystem is the way a solution is organized in logic. It is not directly deployed on the technology architecture, as a system component instance is. (That's why it's shown with a dotted line in the picture below.) A subsystem can have one or many (sub)system component instances.
See the diagram below. A system component instance actually does (at least part of) what the system is made to do. A system component instance is physical--you actually deploy it on a processing node. In a car, the system component instance for the passenger-holding subsystem would include the actual metal and plastic frame of the car and the seats you actually sit on.
A system component instance has the following qualities:
It's a modular unit of functionality. That is, it's a package that does one thing--such as a car radio. If it stops working, you can replace it with another radio--another instance of the same system component.
It's logically isolated from other system components; its functionality comes through defined interfaces, and it may use another component's interface. That is, you have to unplug a few wires to replace a radio, but very few compared to the wiring contained within the radio.
It's associated with a processing node and is actually deployed on the technical infrastructure. In comparison, systems and subsystems are just containers or collections, not directly associated with a processing node except through instances of the system or subsystem components. (That's why in the picture below, they're shown with dotted lines.) You can touch a specific radio, and open it up to see the chips and wiring it's made of. But the car audio subsystem is just a concept.
A system component instance can be associated with one system component and one subsystem.
See the diagram below. A system component is a logical placeholder for the functional design of a related system component instance--that is, it's the particular kind of thing you are going to use to build the system component instance. It specifies both the technology and the service (functionality) that the system component instance implements. A system component instance often can be built with different sets of different functionality, using different technologies. That's why a system component instance is modeled to be able to relate to multiple system components which make up the instance's deployed behavior. For instance, there are many brands of radios that can fit into a car. One will be the best sound quality, another will be easiest to use, and another will be least expensive. But they are all physical radios (so it has a solid, not a dotted, line in the picture below), and using any one of them gives the car an audio subsystem.
When you say that a system should be deleted, it starts a process. The deletion has to be approved by OCIO, privacy, and security, among others. Your system stays in the inventory, flagged for removal, until all these sources approve the deletion. Then the system is removed from the inventory. In some cases, that means it's deleted entirely, in other cases it is merged into another system, depending on what you recommended in your Phase 1 commments.
These items should show up under the Tools and Reports menus, respectively, but there are some problems with Popkin System Architect calling automated menu-building macros. While Popkin is researching this problem, use the following workaround.
Under "Tools", select "Macros", then "Macro Project".
Click the Add button on the window that comes up.
Type "M:" in the File Open window that comes up, then press the Enter key.
For the System Wizard, select the wizard folder, the dearWizard.mac file, then click on "Open". For reports, select the reports folder, select a file that ends in ".mac", then click on "Open". (If there is more than one file, repeat steps 2, 3, and 4 for each one.)
Check the Enable Automatic Macros box.
Click on "OK".
These steps should associate the menu items with your personal profile, so you won't need to go through these steps again.
This just means your Citrix client security wasn't set up correctly. To set it up,
Open DEAR,
On the icon bar in your screen's bottom right corner, double-click the ICA icon.
In the window that opens, select the line that starts with "IBCDENPSA". (It ends with different letters, such as "CTX1", for different users. Don't confuse this with the line that starts with "System Architect".)
Click the Security button at right.
In the window that comes up, select "Full Access"
Select "Never ask me again for this application"
Click "OK"
If this doesn't fix the problem, call the helpdesk at (303) 969-7777 or 1 (888) 269-0310 or email them at nbcden_itsc@nbc.gov
You can call at (303) 969-7777 or 1 (888) 269-0310, or email at nbcden_itsc@nbc.gov. For a basic question, you may be referred to this FAQ page or to DEAR's getting-started guide. Login, network, and access problems get referred to the NBC network and Citrix administrators, who contact the user to work through the problem. Complex problems get referred to the DOI/DEAR Level 2 support team or the Popkin Software Level 3 support team, who then contact the user to further work through the problem. NBC QA will contact the user on any ticket that is open too long, to see if the user is satisfied with what's being done about the problem. The DOI/DEAR Level 2 escalation team gets involved when a problem isn't acted on according to its priority.
There are four priority levels for tickets:
Immediate response (DEAR is down, user can't connect or access, user unable to work)
1-hour response time (DEAR functionality issue)
4-hour response time (general functionality or technical issue)
Lower priority (enhancements and special requests)
Submit a help-desk ticket immediately to avoid lost time and lost data. We have backups of your work, so if there is an error, we can restore your data.
You can update minor mistakes in the wizard in real time. If there get to be too many of them, though, it becomes a major issue and you should submit a help-desk ticket.
That can happen when the subsystem link is removed but the subsystem isn't actually deleted. Unfortunately, it's hard to tell if this is done by accident, or intentionally. So, during Phase 3, if you want a subsystem removed, you must go to the system that has the subsystem linked, and remove the link, but don't remove the subsystem. At the end of Phase 3, when things are merged, a script will remove all unlinked subsystems.
You'll know if you've done it correctly if the Phase 3 report, "System Architecture Hierarchy (System Modeling)" doesn't show the unlinked subsystem.
The reason you should not try to physically delete the subsystem is that within the master DEAR, the subsystem record still exists, so it will magically reappear after a merge.
Your data is fine, but System Architect didn't recognize your rename. This happens sometimes if you delete, then add again, then rename, because when it is added again, it has the same name but a new ID. It loses the traceability to the previous definition of that name. You'll need to submit a help-desk ticket to have an administrator rename it.
Compare what you know against the DEAR reports. To get the reports, run PHASE-TWO.RPT or get all the reports from the support desk. DEAR generates nightly Zip files of your reports for your BEAR. Starting in Phase 3b (mid-August 2004), you can go to the IEA website for regularly updated reports.
No, they are still being approved by your bureau CIO. While they are being reviewed, their status is "Checked out to the OCIO", so these systems will show up in reports but not in the wizard. All these updates will be made when Phase 3b starts (mid-August). Any that the CIO decides to keep will have their status changed to "Current" instead of "Remove".
Investment. A system has one investment in DEAR, but an investment can have many systems. Select the system you want in the wizard. Expand it to see its investment. Then you can relate either to the Intermediate Outcome or End Outcome levels.
It is the investment that fulfills the strategy, not the IT solution. The overall investment covers the solution, management, and execution. A system is just a piece of the investment.
Either, but not both. If you have detailed enough data to describe it, the intermediate outcome level is best. Intermediate outcomes are children of specific end outcomes, so the end outcome doesn't have to be mapped to.
Map to the end outcome level. If you can't get in touch with the system owner, use the description to come up with an outcome, and check it with the system owner later.
The best sources of information are Exhibit 300s and 300-1s. Try to find as many artifacts as you can before calling your interviewees. They will appreciate the homework you do ahead of time, since it is much easier to validate information already collected than to start from scratch. If there really isn't any information you can find before the interview, after you explain the objectives, ask your interviewee if there is anything you can read that will save interview time.
DEAR doesn't have a field yet, but there is a field for this in eCPIC for the Exhibit 300. You can also conact your bureau's representative at the Office of Performance and Planning (PPP), though performance results are not currently managed by PPP.
Yes, over 200 person roles have been loaded. These are mostly business case contacts, CPIC contacts, and project managers for systems with 300s or 300-1s.
Yes, but not as many as for person roles. These were mostly provided by NBC, who loaded Contributing Organization for investments. Check the investment object in DEAR, and look at the Org/Program tab for this information. Some of this information did not get to the systems, since it wasn't always clear what role the organization played as a contributor.
Check Exhibit 300's Information for Contacts or Contributing Organizations. If the C&A team has an Asset Valuation Guide (AVG), you can load that information; there are many person roles in the first section. Also AVGs may have information about who uses and hosts the system.
Add roles whether or not you are the managing partner for a system. System Architect will sort out what both you and the partner put in about the system. The same thing happens for system uses.
So if, for instance, you are the managing partner for an interagency facilities management system, you should add the organizations that play a role. If you are not the managing partner (for instance, you use DEAR, but DOI is the managing partner) you should still add the other organizations that play a role.
Try to use the originally developed list of roles if you can, so that names aren't duplicated. But if you really have discovered a new person role or organization role, submit a help desk ticket to have it reviewed and added. We will then walk you through updating your spreadsheet so that the role will be added correctly when it is batch loaded.
Your encyclopedia should be at U:\BEAR\\WIP\BEAR_.UDL. For example, the MMS BEAR would be at U:\BEAR\MMS\WIP\BEAR_MMS.UDL. However, you will not be able to load it if you do not have permissions to that organization's encyclopedia.
In the Encyclopedia browser, open the system definition
Add the systems that will be replaced into the "Replaces Systems" field
Copy existing sub-systems, components, etc. as needed:
Export the sub-systems (or components, etc.)
Edit the CSV file to remove any unwanted sub-systems
(For SUB-SYSTEM only, remove the System Component Instances)
Change the sub-system's system name and version to the new system name and version
Import the edited CSV file
Add the newly imported sub-systems to the system's Sub Systems field (very important! if you don't do this, they will be deleted on the next build.)
repeat with System Components as needed. Be sure to change SCIs system and sub system name and version fields to agree with the new system and sub-system.