EKD - Enterprise Knowledge Development

What EKD is?        see also The purpose of using EKP

What EKD is not?

EKD framework

Goals Model (GM)

GM focuses on describing the goals of the enterprise. Here we describe what the enterprise and its employees want to achieve, or to avoid, and when. Goals Models usually clarify questions, such as: where should the organisation be moving, that are the goals of the organisation what are the importance, criticality, and priorities of these goals, how are goals related to each other, which problems are hindering achievement of goals.
 

Business Rule Model (BRM)

BRM is used to define and maintain explicitly formulated business rules, consistent with the Goals Model. Business Rules may be seen as operationalisation or limits of goals
Business Rule Model usually clarifies questions, such as: which rules affect the organisation’s goals, are there any policies stated, how is a business rule related a goal, how can goals be supported by rules.
 

Concepts Model (CM)

CM is used to strictly define the "things" and "phenomena" one is talking about in the other models. We represent enterprise concepts, attributes, and relationships. Concepts are used to define more strictly expressions in the Goals Model as well as the content of information sets in the Business Processes Model.
Concepts Model usually clarifies questions, such as: what concepts are recognised in the enterprise (including their relationships to goals, activities and processes, and actors), how are they defined, what business rules and constraints monitor these objects and concepts.
 

Business Processes Model (BPM)

BPM is used to define enterprise processes, the way they interact and the way they handle information as well as material. A business process is assumed to consume input in terms of information and/or material and produce output of information and/or material. In general, the BRM is similar to what is used in traditional data-flow diagram models.
Business Process Model usually clarifies questions, such as: which business activities and processes are recognised in the organisation, or should be there, to manage the organisation in agreement with its goals? How should the business processes, tasks, etc. be performed (workflows, state transitions, or process models)? Which are their information needs?
 

Actors and Resources Model (ARM)

ARM is used to describe how different actors and resources are related to each other and how they are related to components of the Goals Model, and to components of the Business Processes Model. For instance, an actor may be the responsible for a particular process in the BPM or, the actor may pursue a particular goal in the GM.
Actors and Resources Model usually clarifies questions, such as: who is/should be performing which processes and tasks, how is the reporting and responsibility structure between actors defined?
 

Technical Components and Requirements Model (TCRM)

TCRM becomes relevant when the purpose of EKD is to aid in defining requirements for the development of an information system. Attention is focused on the technical system that is needed to support the goals, processes, and actors of the enterprise. Initially one needs to develop a set of high level requirements or goals, for the information system as a whole. Based on these, we attempt to structure the information system in a number of subsystems, or technical components. TCRM is an initial attempt to define the overall structure and properties of the information system to support the business activities, as defined in the BPM.
The Technical Components and Requirements Model usually clarifies questions, such as: what are the requirements for the information system to be developed, which requirements are generated by the business processes, which potential has emerging information and communication technology for process improvement.
 

Relationships between sub-models

Each of these sub-models includes a number of components describing different aspects of the enterprise. For example, the Goals Model contains business goals, business problems, divided into threats and weaknesses, causes, business opportunities, and constraints. The modelling components of the sub-models are related between themselves within a sub-model (intra-model relationships), as well as with components of other sub-models (inter-model relationships).
Figure above shows inter-model relationships. The ability to trace decisions, components and other aspects throughout the enterprise is dependent on the use and understanding of these relationships. When developing a full enterprise model, these relationships between components of the different sub-models play an essential role. For instance, statements in the Goals Model allow different concepts to be defined more clearly in the Concepts Model. A link is then specified between the corresponding Goals Model component and the concepts in the Concepts Model. In the same way, goals in the Goals Model motivate particular processes in the Business Processes Model. The processes are needed to achieve the goals stated. A link therefore is defined between a goal and the process. Links between models make the model traceable. They show, for instance, why certain processes and information system requirements have been introduced. The figure below shows a fraction of an enterprise model. Inter-model links are shown with dashed arrows.

There exist, however, limitations in the way sub-models and their relationships may be populated. These are controlled by a number of static as well as dynamic consistency rules, which control their permissible state transitions. These are necessary because they allow for analysis and comparison. How each sub-model focuses on a specific view of the enterprise will be described in detail in the following chapter.

[BACK]