Architecting and designing > Federal Enterprise Architecture Framework (FEAF) > FEAF 1 – integrated Reference Model Architect (iRMA) > iRMA tutorial > Understanding the iRMA metamodel
  
Understanding the iRMA metamodel
Models need to have an organized and predictable structure in order to be easily understood and used. The structure of models in the iRMA is governed by a higher level model called a metamodel.
In this section of the tutorial, you will learn:
What is a metamodel?
Why are metamodels needed?
The structure of the iRMA metamodel.
What is a metamodel?
A metamodel is the logical structure above the implementation of a model. For example, the metamodel for the English language are the components of language (nouns, verbs, and so on.) and how they are related (grammar/sentence structure). Meta-models define how things can be related in consistent and meaningful ways. In addition, they specify the properties (attributes) that a specific meta-concept possesses.
Why are metamodels needed?
Enterprise architectures are typically complex models (have many relationships) and are large (have many actual types and combinations of relationships). In order to enable predictable capture, analysis and use of EAs by users, the complexity and scale of an EA model needs to be constrained.
Metamodels help determine what can and cannot be modeled at an implementation level. Properties are constrained in both what they are and which types and relationships they belong to. The ability to navigate across the metamodel, reporting types, relationships between them and their property data is constrained by the metamodel implementation.
A metamodel does not necessarily specify all implementation details. For example; type of diagram and the symbol and relationship types assigned to it are typically not specified at a metamodel level. However, all of the symbols and relationship types should be.
The IRMA metamodel
This graphic is described in the surrounding text.
The IRMA metamodel can be divided into two primary sections: OMB reference model domains with their meta-concepts and a basic set of typical enterprise architecture meta-concepts. These latter are intended as interfaces/placeholders for linking the reference model domains to existing department/agency EA meta-concepts.
Typical enterprise architecture meta-concepts
Enterprise Architecture meta-concepts
Enterprise Architecture meta-concepts are intended as interfaces/placeholders for existing department/agency EA meta-concepts.
Business Activity meta-concept
To minimize initial complexity, OMB only specified three levels of the BRM down to Sub-Function. Departments and Agency Function/Activity and Process models are typically, one or more levels below the BRM-Sub-function. The purpose of the Business Activity Meta-concept is to serve as a consistent link to existing Departments/Agency EA Function/Activity and Process models.
Postal Services provides for the timely and consistent exchange and delivery of mail and packages between businesses, organizations, and residents of the United States or between businesses, organizations, and residents of the United States and the rest of the world. It also includes the nation-wide retail infrastructure required to make Postal Services easily accessible to customers. (Note: The commercial function of mail is more closely aligned with the “Business and Industry Development”). Sub-Function in the “Economic Development Line of Business” The international commercial function of mail is more closely aligned with the “Global Trade” Sub-Function in the “International Affairs” Line of Business).
Next
See also
iRMA tutorial