NIEM provides a consistent, repeatable, and reusable way to build information exchanges. There are a number of ways to develop an information exchange. Every organization within an agency, possibly every developer within an organization, may have a preferred way to do development—that’s the point.
We are currently working to modernize our training materials. We’re giving NIEM training a major revamp—updating the content, changing the delivery format in favor of user-driven tutorials and easy-to-use reference content, and moving all training materials to NIEM’s GitHub site. In addition to the content on this page, be sure to check out the technical materials and reference content currently in beta on NIEM.github.io/training.
Since NIEM exchange developers follow the same development lifecycle, they can borrow from and reuse each other's work. An exchange developed for one organizational business need could be reused (partially or fully) for a different need within that or another organization.
In an era when return on investment has never been more important to government services, NIEM enables organizations to exchange information in a manner that is both effective and efficient. Be sure to check out the NIEM Cost Model, which allows users to quantify the associated costs of adopting NIEM.
As a point of reference, let’s explore the graphic below as a simple introduction to NIEM architecture.
To use NIEM, you normally build an Information Exchange Package Documentation. An IEPD defines a recurring message in XML and is built to satisfy information exchange business requirements.
The developer may also extend that content as needed to account for information requirements that are not yet addressed in NIEM. The IEPD will ultimately define XML instance documents that will contain the information to be exchanged. Extended and new content developed in IEPD extension schema documents should be considered for future model updates. In turn, domain and core model updates will be harmonized and integrated into future NIEM releases. In this way, NIEM evolves with new and changing needs.
From a technical perspective, an IEPD is a set of XML schema documents that define instance XML documents which, in turn, will tag and carry the data and information to be exchanged. For example, when you want to exchange "person" data and its related attributes, you will leverage (essentially reuse from a NIEM release) XML schema components that define the “person” related tags and structures.
From the business perspective, an IEPD provides documentation such as business scenarios and other aspects of the business requirements for the exchange, including a catalog of its content, a change log, a conformance assertion, etc. In addition, reusing existing IEPDs that meet or can be easily adapted for similar business requirements is encouraged, and can save time and money!
NIEM follows a six-phased approach to IEPD development:
You can help expedite the work in this phase by collecting prior documentation created for the information exchange, or a similar information exchange. IEPDs are designed to be re-usable, so leveraging already existing exchanges can reduce the work required to build a new exchange.
Examples of documentation include:
Additional information may include insights into the current technical architecture of exchange partners, use of external standards, type of data being shared, and policy-related concerns associated with the exchange.
Using information gathered, you will begin to define the business processes surrounding the information exchange though graphical representations of the information exchange requirements. There are three main types of business representations included in building a NIEM-based exchange.
Sequence diagram: A graphical representation of the messages sent sequentially within an information exchange. This should include both the messages sent and the systems and applications involved in the information exchange. A sample sequence diagram is shown below.
Business process diagram: A textual or graphical representation of the activities involved in an exchange, similar to a work flow diagram. Business processes should be used in the development of use cases. A sample sequence diagram is shown below.
Use case diagram: A graphical representation of the functionality of a particular information exchange as perceived through an external observer. Use cases are effective for identifying the actors (or individuals) in an exchange and how those actors will interact. NIEM does not prescribe any one method, however, we find Unified Modeling Language (UML) has been used successfully to develop use cases. A sample use case diagram is shown below.
The business rules and requirements help provide some clarity around the exchange, and how and what data will be represented as part of the exchange. This phase is a direct result of the work done in the Scenario Planning phase — the sequence diagrams, business process diagrams, and use cases are used as inputs into this phase.
Two artifacts that should be documented during this phase of the IEPD Lifecycle are business rules and business requirements. Together, they help define the exchange as well as the expectations of the exchange.
Example of a business case
A large city identified the need to create a series of exchanges that would allow parents, city-wide, to apply online for their children’s school meals program and automate the processing of the request between the Human Services Agency and the school.
This will be implemented via a web-based service that, upon submission, will automatically check the city’s Human Services agency database to ensure the applicant is from a low income family and qualifies for the school meals program. If qualified, the web-based service will then notify the respective school to add the child to the meal program.
Currently, the only means the city has to process school meal program applications is through paper-based applications at the city Human Services Agency office. Once approved, the Human Services Agency faxes approved applications to the particular school where the child attends. Overall, it is a manual process that inhibits timely delivery of citizen services.
Examples of good business requirements
Candidate message exchange packages
Each school in the city shall be able to receive a monthly report of every child in their school who is currently enrolled in the school meals program.
The phase is important in the process of moving from requirements to actual design of the data structures to meet those requirements. The Exchange Content Model created is a primary driver of the data objects and relationships among those objects that will be used within the information exchange.
There are two artifacts associated with the Map and Model phase of building a NIEM-based exchange—Exchange Content Model and Mapping document. First, you will create an Exchange Content Model. Then, you will create a Mapping document to record how the required objects map to equivalent NIEM data objects.
Exchange Content Model: A graphical representation of the data and relationships involved in the information exchange. Exchange Content Models consist of objects, their related elements, and the associations between those objects.
Exchange Content Models display the content and structure of the data being exchanged. Although no specific methodology is required, the most commonly used methodology is based on Unified Modeling Language (UML) Class Diagrams. UML Class Diagrams consist of objects, their related elements, and the associations between those objects. The Exchange Content Model does not have to explicitly use data objects from the NIEM model.
Example of an Exchange Content Model
Mapping Document: Aligns elements identified in your Exchange Content Model to the NIEM model.
Example of a Mapping Document
To create a Mapping Document, the exchange developer will map the elements and objects in the Exchange Content Model to elements in NIEM. Each data object should be mapped to an element or type in NIEM, if possible.
Reuse of NIEM data elements increases consistency across exchanges and reduces development time for data definitions. A golden rule of NIEM is that if it exists in NIEM, use it—don't recreate it. During the mapping process, existing related IEPDs should be reviewed to evaluate reuse.
However, mapping to NIEM should not be forced if it doesn't make sense. Instead, exchange developers should create “extensions” to the NIEM model. A Mapping Document can also serve as a communication tool to relate the level of reuse in NIEM to business users.
The purpose of this phase is to create the XML schema documents that define the XML instances that will be exchanged in an implementation. The exchange developers will use the Exchange Content Model and Mapping document created during the previous phase as inputs to build the schema documents.
XML Schema documents: A type of XML document used to structure and constrain the XML document instances that carry the data for an information exchange. XML schema documents that are typically included in an IEPD are subsets and extensions. However, reference, constraint, and external schema documents can also be used in an IEPD. Note that subset, extension, and reference schema documents are NIEM-conformant; external and constraint schema documents are not.
XML schema documents can either be coded by hand or generated through tools. Visit the tools catalog for more information on tools that can be used to generate XML schema automatically.
NOTE: Manual design of subset schema documents from NIEM reference schema documents is difficult. A subset is a careful combination of both the requirements (what the user wants in the exchange) and dependencies (types, elements, and attributes that a correct subset needs to support the required components). A tool that has NIEM ‘baked-in’ is highly recommended for generating schema document subsets without overlooking dependencies.
Other XML documents: In addition to schema documents, there are other XML artifacts required and recommended to include within an IEPD. Here are a few:
The purpose of this phase is to complete IEPD documentation and then assemble all artifacts into a single package. At this point in the development process, all technical artifacts should be completed and ready to include within the IEPD.
See the MPD Specification 3.0 for details on all required and recommended artifacts in IEPDs. Refer to http://reference.niem.gov/niem/specification/model-package-description/3.0/model-package-description-3.0.html#appendix_C.
Publish the IEPD to an online repository for reuse and implement the information exchange.
Publish: Publishing an IEPD allows others to discover it and use it in other exchanges. This ability to reuse IEPDs is part of NIEM’s overall value proposition.
Implement: When creating an information exchange, you rarely ever use NIEM by itself. Depending on business requirements, there are other aspects of information exchange implementations that are required, including access controls, policy automation, transmission protocol, and others.
Maintain: An information exchange needs to be maintained throughout its existence. Best practices for maintaining IEPDs include:
Visit our GitHub site for more information on your most commonly asked questions. This includes:
Visit the technical specifications that outline the rules and requirements for NIEM conformance and use. They also describe key aspects of NIEM architecture, tooling and model versioning.
The NIEM technical architecture provides integration capabilities to leverage the Intelligence Community Information Security Markup (IC-ISM), as well as other IC security markups such as Need to Know (NTK).
Check out our ISM IEPD for an example on how to apply the IC-ISM markings.