An integrated data model can connect the applications, functions, and disciplines of a company. It can be a foundation for service oriented architectures, business process automation, and master data management. The process towards establishing an integrated model can be long and winding. While data modeling methodologies are suitable for documenting the end result of this process, they may hinder more than facilitate its progress. In particular, prematurely introducing a precise common representation, may alientate groups of stakeholders, leading to a “common” model with a bias towards a few perspectives. An approach more adjusted to group dynamics and social learning is needed. Physical data models and logical information models should be complemented by conceptual knowledge models. This post presents some of the challenges involved, while a later post outlines a knowledge architecture approach to integrating data models. Read the rest of this entry »

Innovative design is the most important competitive factor for global engineering and manufacturing. Critical challenges include cutting lead times for new products, increasing stakeholder involvement, facilitating life-cycle knowledge sharing, service provisioning, and support. Current IT solutions for product lifecycle management fail to meet these challenges because they are built to perform routine information processing, rather than support agile creative work.

Active knowledge modeling is a family of methodologies that address this situation, utilizing model-driven application platforms. This post presents an overview of different methodologies applied to implement pragmatic and powerful design platforms, by building and utilizing active knowledge architectures (AKA).

Read the rest of this entry »

My first impression of Microsoft Oslo and the M modeling language was quite positive. In particular, their approach seemed to take better care of instances than e.g. UML does, and I applauded the use of extents (instance collections) rather than types to represent repository database tables.

Upon closer examination, however, some doubts appeared. The syntax seems unneccesarily complex, and the repository and M representations goes out of synch with regard to such basic functions as subtyping and the identity of the instances. This post proposes some adjustments to simplify M and better align the visual, textual and repository representations of Oslo.   Read the rest of this entry »

Several languages have been proposed for business process modelling. Though most of them follow the conventional representation of processes as a series of steps, they emphasize different aspects of processes and related structures, such as organizations, products, and data. Consequently, they are suited for different kinds of processes. Even if you are determined to use a particular technique, knowledge of alternative approaches can still guide the modelling, by surfacing complementary points of view. In addition to the common transformational process models, this post discusses block structured languages, storytelling, and process modeling languages that are hierarchical, flow-oriented, role-oriented, communication-oriented, declarative, goal-oriented, timelines, product and document state machines etc. Read the rest of this entry »

Properties define the data values that are important in a domain. In product design, properties and parameters are used for quantifying requirements, for setting agreed upon targets, and for assessing the qualities of different solutions. Product data management (PDM) therefore places properties at the centre of attention, and properties are perhaps the most important kind of elements in PDM standards, cf. independent property definition in STEP, and e.g. the DIN product property dictionary. Design methodology processes are defined according to what kind of properties are defined, related, mapped, balanced, estimated, calculated etc. in each step. Generally, required and target properties are defined long before the objects that will eventually possess them are properly identified or classified.

Yet in IT, properties and attributes are normally treated as second class citizens compared to objects. In database schema, they define the columns of entities, while in object oriented design, they are just subordinate features of object classes. OWL (Web Ontology Language) is a notable exception. It supports property modeling independent of object classes. In the reflective variant OWL Full users may remove the differences between objects and properties, to model features of and relationships between properties. This variant is however seldom applied, because it cannot guarantee sound formal reasoning for automatic execution. In information systems research, Jeffrey Parsons has shown how properties determine classification structures, rather than vice versa. These examples, however, are exceptions to the common practice. This is why our modeling principles include the representation of properties as first class citizens. Read the rest of this entry »