Large projects are complex, involving multiple products, disciplines, methodologies, techniques, systems and stakeholders. They often fail to meet expectations, schedules and budgets, and results are often poorly validated and managed. Current IT support to project definition, planning, execution and management is fragmented and rigid. Lifecycle data exchange is transformative rather than evolutionary. Innovation is not driven by evolution, embedding experiences and lessons-learned. There are many uncertainties and unknown dependencies in the early phases, many nonproductive meetings, stove-piped and sequential information flows, poor data management, and limited knowledge sharing. Collaborative design, cross-functional team working, and service composition are inhibited. Work environments and user interfaces are rigid and discipline-specific.

This post raises the questions: Are we wrongly trying to generalize and program creative work, collaborative and adaptive environments, and human behavior? Are we doing right to standardize properties, embedding their parameters and values in code? Can this approach serve complex customers with dynamic demands for controlling dependencies, supporting innovation, and automating adaptation? Read the rest of this entry »

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 »

Computer support to Product Design and Life-Cycle Management is currently dominated by PLM systems, and industry is not very happy with the support provided. Industrial design methodologies and PLM systems create many disjoint, pre-typed product structures. This approach belongs to the era of communicating product knowledge as engineering drawings. In this post, we discuss the need for replacing these static structures by a single federated product model, from which any structure or aspect can be derived.  The federated product model is managed as a family of configurable system and component models, as part of an active knowledge architecture (AKA). With the advent of AKA we see completely new approaches, concepts, operational methodologies, visual modeling methods, enterprise architectures and design solutions emerging. 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 »

Product Life-cycle Management (PLM) systems have been developed and implemented since the early 1990s. Early solutions were based on a chain of application systems with proprietary user interfaces, information logistics and databases. At the turn of the century product data management standards, protocols and meta-data for application integration matured. Knowledge Based Engineering (KBE), process and collaboration capabilities were introduced. Ten years later customers are still not satisfied with the capabilities offered and value delivered by current solutions. Read the rest of this entry »