Meta model

The LUY meta model sets the basis of the whole application, defining its structure of data and relations. The meta model is based on the best practice EAM method developed by our company iteratec, combining experience from more than 100 successful EAM projects across different industries. 

The structure view of the metamodel in LUY Classic can be edited and uploaded through customizing. In LUY Nova, this structure view is adjusted automatically.

Building block types

The LUY meta model consists of the following customizable building block types:

• Business domain: Business domains are used to arbitrarily group elements of the business and information system architecture. Although they are primarily associated with coarse-grained capabilities (e.g., product management, marketing, sales, etc.), the grouping can follow various logical criteria.

  For example, a geographically oriented structure or grouping according to existing internal company governance rules is conceivable.

  Building block elements can be assigned to different business domains simultaneously.
  

• Business process: A business process is a sequence of logically related tasks, which are considered as sub-processes and together lead to the achievement of a company goal. A business process thus represents HOW a set corporate goal is to be achieved. In EAM, business processes are usually structured hierarchically. The main processes of the value chain can usually be found at the top level. In EAM it is not necessary to map a business process down to the individual activities. As a rule, it is not sufficient to model its structure down to the third hierarchical level in order to analyze the architectural aspects of IT support and, if necessary, to identify existing optimization potential or need for action.

  In general, it is important to model the hierarchy of the business processes so deeply that the differentiating features can be identified. This could include, for example, the detection of a redundancy in the system-side process support.
  

• Capabilities: Capability is "a specific ability or capacity that an organization can possess or exchange to achieve a specific purpose or result."

  It is crucial that a business capability describes WHAT a company must be able to do, and not how and by whom corporate goals are achieved. Thus, business skills are initially considered completely separately from business processes and organizational structures. They are also much more stable to look at, since both organizational structures and business processes are frequently optimized and changed. On the other hand, the ability to do business is much less frequently expanded by new innovative capabilities, usually due to technological developments or new market requirements.

  As part of business architecture practice, there is a distinction between "what gets done" from "who does it within the organization" and "how the business derives value from that activity." A business capability can be something that is in place today or something that is required to enable a new direction or strategy.
  Therefore, When capabilities are integrated into a business capability map, business capabilities represents all of the skills available to an organization to run its business.

• Product: Products, as results of a company's value chain (goods or services), become important for EAM when the IT support of business processes or business capabilities has to be documented and analyzed product-specifically. This is not always the case and is mainly done in the financial industry.
  

• Business unit: Business units represent the organizational structure of the company. For EAM, they are important because they help answer the question WHO is involved in business processes and WHO needs IT support.

  Business units are to be filed in hierarchical form (parent-child relationship). As a rule, it is not sufficient to model the hierarchy down to the third hierarchical level in order to analyze the architectural aspects of IT support and to identify any existing optimization potential or need for action.

  In general, it is important to model the organizational hierarchy so deeply that the differentiating features are recognizable. This could include, for example, the detection of a redundancy in the system-side process support.
  

• Business object: A business object is used to represent information values relevant to business management, which are realized by data objects.

  Business objects can be accessed by a business process, capability, business interaction, business event, or business service. A business object can have various relationships with other business objects. The name of a business object should preferably be a noun.
  

• Information system: An information system is a software system that directly supports business capabilities. It is used by business units in business processes to enable the achievement of set corporate goals.

  Information systems process and store data that is important for the company. They help to obtain information from the data and make it available for further processing.

  At runtime, information systems require a platform that consists of hardware and software components and makes all relevant services available. The platform could, for example, consist of a server with the required processor and memory capacity, as well as the operating system, database management system and other software components installed on it.

• Information system domain: Information system domains are used to arbitrarily group any building block elements of the enterprise architecture. The grouping can be modeled according to various technological or functional rules. Domains are often modeled to support governance processes.

  Building block elements can be assigned to different information system domains simultaneously.
  

• Information flow: An information system is a software system that directly supports business capabilities. It is used by business units in business processes to enable the achievement of set corporate goals.

  Information systems process and store data that is important for the company. They help to obtain information from the data and make it available for further processing.

  At runtime, information systems require a platform that consists of hardware and software components and makes all relevant services available. The platform could, for example, consist of a server with the required processor and memory capacity, as well as the operating system, database management system and other software components installed on it.
  

• IT service: An IT service describes a service that is required for the operation of information systems or for the direct support of business units, business processes or capabilities. Examples are:
  a. An information system requires a platform (PaaS, IaaS, or similar), an AD service, a storage system, etc.
  b. Business users need printer services, a helpdesk service, a desktop management service, etc.

  An IT service usually bundles hardware and software components that are necessary to provide the IT service or directly represent a platform service.

  Services can be described and categorized in detail using custom attributes.
  

• Architectural domain: Architecture domains are used to arbitrarily group building block elements of the information system and technical architecture. The grouping can be modeled according to various technological or functional rules.

  Architecture domains are often used for standardization purposes. This allows a catalog of technical components or information systems to be modeled that conform to the company standard.

  Building block elements can be assigned to different architecture domains simultaneously.

• Technical component: A technical component is a software component that is required by one or more information systems at runtime or directly supports an information flow. These include operating systems, application servers, database management systems, frameworks, ETL tools, etc.

  Elements of the desktop equipment, such as MS Office and Acrobat Reader, are also modeled as technical components. Although they are used by almost all business units, they do not directly support any business capability. For example, Excel only offers a runtime environment for more complex evaluations based on Visual Basic and Power Query.

  A catalog of standard components can be maintained as an architecture domain to encourage a standardization effort. An information system conforms to the standardization approach if it only uses the standard components.
  

• Infrastructure element: An infrastructure element is a hardware component that is used as a platform for installing information systems and technical modules. This includes both physical and virtual servers, desktops and cluster systems.

  Servers and hardware clusters are the only architectural IT building block elements that are instantiated, e.g., each server has a specific location.

  From the EAM perspective, desktops are only considered logically, if at all, in order to model the equipment with standard and optional components (technical building blocks). This can depend on the role of the respective user (e.g. the business unit). A developer's desktop is typically populated with different components than a marketing or customer service representative's desktop.
  

• Project: A project is a goal-oriented activity or undertaking that is essentially characterized by the uniqueness of its conditions as a whole, e.g., project objectives, differentiation from other projects, project-specific design, or temporal, financial, personnel, and other constraints.

Business mapping

A business mapping represents the relation between 2-7 of the following seven building block types: products, business processes, business units, capabilities, business objects, IT services and information systems. It is possible to use up to (all) seven building block types in a business mapping. In a business mapping, any combination of these seven building block types is possible. You can assign custom attributes to a business mapping. From a technical point of view, a business mapping is a special type of relation.

Business mappings are treated like building block types by Plugin API, REST API and iteraQL.

Relations

All building block types in LUY are connected to other building block types. These connections are called relations. Relations are depicted in the LUY meta model via lines connecting two or more building block types, as shown in the meta model above. 

All building block types are connected to other elements of their own type, which is called a self-relation. The following self-relations exist in LUY:

• Hierarchy: Superordinate ↔ subordinate (one to many)
  Available for all building block types

• Usage: Used ↔ using (many to many)
  Available for business process, capability, information system, IT service, technical component, infrastructure element and project

• Successor: Successor ↔ predecessor (many to many)
  Available for business process, capability, information flow, information system, IT service, technical component and infrastructure element

• Specialization: Specialized ↔ specializing (one to many)
  Available for business objects

Relations are treated like building block types by Plugin API, REST API and iteraQL.

Attributes

Attributes serve to specify the building block types which they are assigned to in more detail, e.g., with enumeration, numeric, range, binary values. Common examples of attributes are costs, accountability, status.

Self-defined attributes can be customized. 

Attributes predefined by LUY are:

• General attributes for each building block type:

  • Id

  • Description

  • Hierarchy level: This attribute shows the hierarchy structure based on a parent/child relation. It is possible to filter, color or sort by hierarchy level in diagrams or list views.

  • Last modification user

  • Last modification time

  • Name

  • Position

  • Version*
    * Only for the building block types information systems and technical components
    * Supported only in the frontend (not global filter)
    * Name of the building block type which has following syntax: <text> # <version>
    The <version> part is used to identify the version

• Direction attributes:

  • "Interfacedirection" for information flows

  • "Direction" of the relation between information flow and business object. 
    In both cases, the attribute can have the values 1^st->2^nd, 2^nd->1^st, both and none.

Metamodel reference names (technical names)

The following list provides the reference names for all technical building block and relation types including their system attributes. These are used within iteraQL, Plugin API and REST API:

Building blocks

*Square brackets denote custom attributes present in the demo data set of LUY.

Relations

Self-Referencing Relations

The following table depicts the naming convention for each self-referencing relation in both directions.