9/11 Commission Act of 2007
An act passed by Congress based on the report completed by the 9/11 Commission. This act empowers specific agencies and mission areas with the authority, responsibility, and procedures necessary for information sharing.
Accept and Publish
The IEPD is formally accepted by the reviewing authority, after resolving any issues, and the IEPD is published to an online repository. You should establish a review process for IEPDs within your organization if one currently does not exist. An established, effective review process will increase the consistency of IEPDs being developed.
The strategy to adopt NIEM. This strategy varies among stakeholders.
NIEM is valuable in that it does not require, nor dictate how agencies should implement their systems when using NIEM. Many diverse systems can leverage NIEM when exchanging information and there is no standard system requirement associated with NIEM.
The second phase of the IEPD Lifecycle. The purpose of the Analyze Requirements phase is to further elaborate the selected information exchange in order to understand and document the business context and data requirements. The deliverables for this phase are Business Requirements and Business Rules.
Application Programming Interface (API)
Application Programming Interface
Develop clear and accurate design specifications for information exchanges and provide a technical foundation of development. Architects should have experience in understanding different business processes and how these processes are reflected in technology-related solutions. Individuals with prior experience in creating design specifications, specifically with the business processes and design specifications of information sharing, message and system integration, NIEM, and XML, will benefit in this role.
Any tangible and potentially reusable documentation or output pertaining to an existing or potential information exchange
Assemble and Document
The fifth phase of the IEPD Lifecycle. The purpose of the Assemble and Document phase is to prepare and package all required files for this IEPD into a single self-contained, self-documented, and portable archive file. The deliverables for this phase are IEPD Master Document, IEPD Catalog, IEPD Metadata, sample XML instances, and XML stylesheets.
A NIEM construct that represents a relationship among two or more objects. A type, named for the kind of relationship it represents, links multiple objects under specific contexts and may contain properties that are characteristics of the relationship. This allows preservation of the object-oriented design principles of the data model, while allowing more granular specificity of meaning when two or more data objects are related
Interactions between objects that portray structure
A characteristic of an object whose value may be used to help distinguish one instance of an object from others
Augmentation (or Type Augmentation)
A NIEM technique that enables the reuse of type extensions that occur within particular domains for use elsewhere. Type augmentation avoids the need to create new specialized entities and duplicate type extensions that could not have been reused. Instead, the technique simply supplements an existing type with a reusable set of properties required for a given context
The organization or entity (in NIEM, often a domain or community of interest) that has taken ownership of and update responsibility for a particular IEPD or other exchange artifact including schemas, code lists, etc.
Build and Validate
The fourth phase of the IEPD Lifecycle. The purpose of the Build and Validate phase is to create a set of exchange-specific NIEM-conformant XML schemas that form the data model created for the exchange. The deliverables for this phase are NIEM XML Schemas and the XML Wantlist.
Bureau of Justice Assistance (BJA)
A part of the Department of Justice (DoJ)
See Lines of Business
Business Component Library (BCL)
The concept of facilitating the creation and storage of reusable components for NIEM IEPD creation. Business Components typically consist of an aggregation of data components into a construct that serves a specific business need, such as assembling name and address elements to create a Home Address component. These components can then be reused, saving development time and costs and avoiding duplication of effort across NIEM implementations
A common frame of reference across business areas or domains allowing organizations to share information with specific goals or scenarios in mind
The operations and procedures carried out to fulfill a business need or needs
Business Information Exchange Component (BIEC)
A NIEM-conforming XML schema data component definition (for a type, element, attribute, or other XML construct) reused, subsetted, extended, and/or created from NIEM that meets a particular recurring business requirement for an enterprise.
A view of the business at any given point in time. The view can be from a process, data, event or resource perspective, and can be the past, present or future state of the business. Creating a business model is often one of the initial steps when exploring information sharing needs and potentials
Often used as a justification for decisions or actions in a business setting, the business need addresses those outcomes that would most assuredly achieve business success.
Textual or graphical representation of the activities involved in an exchange, similar to a workflow.
A business driver for an information exchange that is primarily an operational or functional requirement.
A specific qualification for data that refers to how it should be structured (field lengths, data constraints, etc.).
Real‐world scenarios that are used to describe or justify a use case for a certain business model
Defines numeric relationships between entities
Describes all of the files and associated metadata within a domain update
A process documenting that a verified and validated exchange package conforms to NIEM information exchange standards