December 17, 2010
Enterprise ontology was a topic of academic research in the 90s, e.g. in Canada, Holland, and Scotland. This early work was informed by industrial practice in enterprise modeling, and emphasized industrial issues like product design, requirements, organization, manufacturing, transportation, quality, inventory etc. The added value of an ontological approach compared to conventional enterprise modeling was however never clear to industrial practitioners, and ontology remained an academic exercise, which was not picked up by leading tool vendors.
Recently, the fad of the “semantic web” has brought forward an even more theoretical approach to enterprise ontology. Its proponents seem unaware of the earlier work. As before, interoperability is the core concern that ontologies are addressing, e.g. in the IDEAS framework. However, it seems that the focus has moved from interoperability of enterprises to exchange of enterprise models. This post questions if such an approach is viable. In the absence of any evidence that demonstrates that ontologies work in practice, I apologize for the theoretical nature of this post. Read the rest of this entry »
December 10, 2010
Enterprise architecture (EA) has been developed by four different disciplines, as shown in the table below.
|Discipline||Focus||Architecture||Frameworks and Techniques|
|Management Consulting||Money||Enterprise Modeling||FEAF, BPM|
|Information Systems (IS)||People||Enterprise Architecture||Zachman, TOGAF, ARIS|
|Software Engineering||Software||Model Driven Architecture||UML, MOF, SOAML|
|Systems Engineering||Hardware||(System of) Systems Architecture||SysML, MODAF, NAF, UPDM|
Enterprise modelling was first applied to analyse industrial operations, extending IDEF and other process modeling notations. Later, information systems people applied similar techniques for aligning the IT with the business it supports, and for IT management in general. After software engineering established object oriented modelling of the internals of software systems, systems engineering adapted these techniques to hardware and software co-design. Systems-of-systems thinking led them to extend their reach beyond technology and into the enterprise realm. Read the rest of this entry »
From industry and defense we have learned that a holistic design approach should be adopted to integrate data and knowledge management. In all knowledge work, the life-cycle management of data structures, properties and parameters, values and ranges, dependencies, rules, decisions, and experiences, require in-depth understanding of the data. This in-depth understanding is workspace dependent, local and possessed by practitioners only.
A holistic design approach should therefore be applied, where data models are defined, adapted, and managed by practitioners in a role-oriented Federated Knowledge Architecture. A knowledge architecture is capable of providing the work contexts required for self-serve distributed data management.
March 23, 2010
Though BPMN has emerged as a dominant business process modeling standard, the jury is still out on whether it is suitable for business people. Even for IT people, some argue that the number of constructs you need to understand in order to build a process model is too large. Future standards for adaptive case management will require even greater end user participation in process modeling.
Consequently, the requirements for a simple, robust, extensible, and flexible modeling framework are growing. Over the years, we have developed a few principles for making modeling languages simpler to use. These principles represent a move away from the prejudice that everything should be defined as classes, which so dominates OO and MDA.
The results of applying these principles to BPMN 2.0 could be a reduction of its size by up to 50%. The resulting framework would also handle typical evolution scenarios better, by removing the need for a lot of type change of individual elements. Finally, it would better support complementary visualizations of the process, like the 12 different process views we described earlier.
The Graphical Modeling Framework (GMF) of Eclipse is a promising open source platform for building your own model editors. We’ve performed a preliminary analysis of GMF as a platform for our methodologies for model-driven applications, and this post highlights its strengths and weaknesses. We also propose directions for future development of GMF that would simplify the use of the framework and extend its capabilities for view management and model execution.
The upside of GMF is that basic functionality can be put together without programming, based on your own domain specific metamodel. Through additional mappings, different diagrams can be integrated into a coherent architecture, and graphical symbols can be customized. Open source makes it easier for software developers to extend the framework.
On the downside, the programming paradigm of Eclipse is at odds with our end user driven approach. Our direct model execution ambition seems difficult to implement inside a framework based on extensive code generation. While we emphasize queries and views for generating role and purpose specific interfaces, GMF relies more on transformation. Read the rest of this entry »
December 9, 2009
Active knowledge modeling (AKM) is a business-centric approach to dynamically reconfigurable service oriented architectures (SOA). Services are made available to users in the situation they find themselves, as captured by enterprise models, in a business level language. The role of a knowledge architecture is to bring purpose and context to the services, and to dynamically compose and configure business solutions from basic services in a manner far more flexible than a conventional BPMS.
We here explore the relationships between AKM and SOA, through SOA reference models, reference architectures, maturity models, and standards. Several frameworks have been developed in order to capture and explain just exactly what service oriented architectures are. This post gives an overview of different frameworks, their purpose and perspectives:
- Reference models developed to explain and create agreement about the meaning of key terms, and the dependencies between them,
- Reference architectures, template solutions for a domain, outlining typical components and subsystems, aspects and layers of services,
- Development and maturity models that describe different generations of SOA, or the path from a conventional application architecture towards a fully service oriented realization.
- Modeling architectures, presenting overviews of modeling methods, which models should be developed and how they fit together, and how the modeling languages are structured.
Web services (WS) standards are also plentiful. People have mapped them before, but the dependencies between different standards are seldom visualized. We present a WS standards map that captures major dependencies.
November 9, 2009
I was recently invited to the second Practice of Enterprise Modeling (PoEM) conference, in Stockholm, 18-19 November. This post introduces the topics that I will talk about there. The objective is to communicate some of our lessons from 15-20 years of enterprise modeling and enterprise architecture development, to highlight advances made, important ideas that were largely forgotten, and to point out directions for future practice development. Some of the lessons presented below are obvious to enterprise modeling practitioners. They are included here because outsiders coming into the field sometimes get them wrong. Other lessons may be more controversial, and they may not be applicable in every situation.