Organizational Knowledge, according to Enterprise Architects, is about understanding how information can be used in an optimal way or finding this optimal way. Organizational Knowledge has many aspects. Some characteristics of organizations hardly change. They are valuable, because they represent business knowledge. In the eyes of Enterprise Architects they represent Knowledge Assets. This makes them useful and valuable as building blocks for the architecture and design of any enterprise.

Because they formalize and describe content we can (re)use them to describe the current and desired organizational behavior. And thus we create the foundation for change. Enterprise Architects recognizes the following Knowledge Assets:

  • Events & Results - they initiate and finalize a Business Process. Events & Results will hardly change in time, especially when they are related to lifetime events of stakeholders
  • Enterprise Functions - actions described independent of the organizational context in which way they are insensible to change and can be reused
  • Enterprise Functions can be “enriched” with explicit knowledge in two ways:

1.Describing knowledge about how functions should be executed from a documentary way
2.Describing knowledge about what the functions need to do for information processing

  • Enterprise Objects - data sets such as invoice and orders will change in time, but data sets described at a higher level (Enterprise and Business Objects) are less sensible to change
    Configuration Components - components of complex things like projects, ships, buildings, airplanes, etc. that can be reused/replicated; for this area Enterprise Architects developed the Component Configuration Framework, distinguishes several different types of knowledge, and is working on several different solutions for configuration replication
  • Business Rules - business rules govern the behavior of an organization and will change, but are a source of knowledge for the organization; also Business Rules turn Knowledge into Actionable Knowledge

Added to that, historical offerings of the organization can be of real value while they often represent engineering and construction knowledge of specific applications or configurations. For example the complete electro-mechanical installation of a submarine. Not only the knowledge of the engineering and construction project can be maintained for reuse reason, but also, the maintenance knowledge of the submarine’s installation, or even how the  submarine should be decomposed in the retire or abandon phase of the ship.

Enterprise Architects BV distinguishes knowledge engineering from knowledge management. The first forms the structural, highly automated part, the latter the more process-oriented part. Within knowledge engineering data (the values) become facts (the attributes or properties, together with their values), and facts become knowledge when first the context or knowledge management rules are described and second the total can be interpreted by an inference engine leading to conclusions.

Likewise we can say that for humans information is about understanding the context of data. If information is to become knowledge humans have to understand how to use this information. Business knowledge is a further distinction of knowledge.

How do we make organizational information or knowledge applicable? Nowadays this is often performed by designing and developing Business Processes and automated Information Systems. To understand how they work we document these processes and information systems. Business Processes are formalized activities that are “chained together” in a formalized way. Decisions, or gateways change the directions of flows within these Business Processes.

These Business Processes and their flows can be managed by workflow, case, and business process management systems. The formalized activities, when automated, can become information applications directing the user how to manage the information. In case of manual activities, these activities can be formalized as mechanized activities with employees handling machines, for example in production processes. Fully manual activities, like accepting the daily post, can be formalized by describing how to perform these activities.

We see that activities are related to two types of business process knowledge. On the one side we see formalized knowledge of manual or automated activities concerning transforming materials and/or data, which we can call the data processing knowledge, and on the other side the explicit knowledge as a description of how these activities should be performed and managed, which we can call documental processing knowledge.

So on the one hand we have knowledge completely contained within the formalized activities and on the other hand we have knowledge contained in the description of how to perform and manage the activity. To address things clearly, we will define the first knowledge, the knowledge of the activity, as Actionable Knowledge, and the latter knowledge, the knowledge describing how to perform and manage the activity as Augmented Knowledge. The Enterprise Architects Knowledge Asset approach is called A3 KAM – Triple A Knowledge Asset Management. Let’s go deeper into that.

Most of the applicable knowledge is implicit – in the heads if people – and will stay implicit as long as there is no necessity to use this applicable knowledge. But of course we can distill this applicable knowledge and transform it into explicit, actionable, and augmented knowledge. How we describe both types of knowledge can be distinguished as a separate, third type of business knowledge:

Architectural Knowledge

This Architectural Knowledge describes the coherence of the different types of components used in Actionable and Augmented Knowledge. This completes the Triple A Knowledge Asset Management (A3 KAM) approach around business functions.

Augmented and Actionable Knowledge make use of the BFM. With the AFM and related tools, see below, both types of Knowledge can be maintained and managed. By defining all Knowledge components in the same database, as defined in the ADOBEÔ Metamodel, including the architecture components of Information and Application Architecture, also Architectural Knowledge becomes available.

Because the knowledge components are easily maintainable, they can be changed and adapted to specific situations that vary in different types of organizations. The BFM is also independent of the organization structure, making it an ideal and most important part of KMS or Knowledge Management System.

Augmented Knowledge

The Augmented Knowledge components are mostly focused on knowledge that the user can use when he/she has to fulfill the job. It describes, in procedures, relationship tables, or documents how Methods, Techniques, Tools, Models, and Business Services are related to the Business Function.

Actionable Knowledge

When the planning of a solution as a business function needs to become Actionable, Business Rules are used. In the example below the Business Function has an incoming and outgoing Parameter, with which Business Functions can communicate with their predecessor or successor functions.

Several tools are available to manage and maintain these different types of knowledge. Also other types of application are foreseen in which way the knowledge assets can be dynamically accessed and interactively managed.

In our Proposition two different frameworks are used:

  • - The GEFF or Generalized Enterprise Function Framework, and
    - The CCF or Construction Configuration Framework.

At this moment A3 KAM is only connected with the GEFF. However, Enterprise Architects have started developments in which A3 KAM  becomes available on different mobile devices in combination with the CCF. In this way knowledge management will not only be A3-oriented, but also mobile. Enterprise Architects believe that this will change the way people use knowledge dramatically.