This manifesto presents the focal topics and objectives of the emerging discipline of enterprise engineering, as it is currently theorized and developed within the CIAO! Network. The purpose of publishing the manifesto is twofold. First, it elucidates the basic premises that are adopted by the members of the network, and that unites them. Second, it clarifies unambiguously the entrance conditions for new members. The manifesto comprises seven postulates, which collectively constitute the Enterprise Engineering Paradigm (EEP). The EEP is endorsed by all member institutes in the EE Network. There is close cooperation of the EE Network with the Enterprise Engineering Institute (www.ee-institute.org) for promoting the practical application of Enterprise Engineering.
The vast majority of strategic initiatives fail, meaning that enterprises are unable to gain success from their strategy. Abundant research indicates that the key reason for strategic failures is the lack of coherence and consistency among the various components of an enterprise. At the same time, the need to operate as a unified and integrated whole is becoming increasingly important. These challenges are dominantly addressed from a functional or managerial perspective, as advocated by management and organization science. Such knowledge is necessary and sufficient for managing an enterprise, but it is inadequate for bringing about changes. To do that, one needs to take a constructional or engineering perspective. Both organizations and software systems are complex and prone to entropy. This means that in the course of time, the costs of bringing about similar changes increase in a way that is known as combinatorial explosion. Regarding (automated) information systems, this has been demonstrated; regarding organizations, it is still a conjecture. Entropy can be reduced and managed effectively through modular design based on atomic elements. The people in an enterprise are collectively responsible for the operation (including management) of the enterprise. In addition, they are collectively responsible for the evolution of the enterprise (adapting to needs for change). These responsibilities can only be borne if one has appropriate knowledge of the enterprise.
Addressing the challenges mentioned above requires a paradigm shift. It is the mission of the discipline of Enterprise Engineering to develop new, appropriate theories, models, methods and other artifacts for the analysis, design, implementation, and governance of enterprises by combining (relevant parts of) management and organization science, information systems science, and computer science. The ambition is to address (all) traditional topics in said disciplines from the Enterprise Engineering Paradigm. The result of our efforts should be theoretically rigorous and practically relevant.
In order to perform optimally and implement changes successfully, enterprises must operate as a unified and integrated whole. Unity and integration can only be achieved through deliberate enterprise development (comprising design, engineering, and implementation) and governance.
Enterprises are essentially social systems, of which the elements are human beings in their role as social individuals, bestowed with appropriate authority and bearing the corresponding responsibility. The operating principle of enterprises is that these human beings enter into and comply with commitments regarding the products (services) that they create (deliver). Commitments are the results of coordination acts, which occur in universal patterns, called transactions.
Note. Human beings may be supported by technical artifacts of all kinds, notably by ICT systems. Therefore, enterprises are often referred to as socio-technical systems. However, only human beings are responsible and accountable for what the supporting technical artifacts do.
There are two distinct perspectives on enterprises (as on all systems): function and construction. All other perspectives are a subdivision of one of these. Accordingly, there are two distinct kinds of models: black-box models and white-box models. White-box models are objective; they regard the construction of a system. Black-box models are subjective; they regard a function of a system. The function is not a system property but a relationship between the system and some stakeholder(s). Both perspectives are needed for developing enterprises.
Note. For convenience sake, we talk about the business of an enterprise when taking the function
perspective of the customer, and about its organization when taking the construction perspective.
In order to manage the complexity of a system (and to reduce and manage its entropy), one must start the constructional design of the system with its ontological model. This is a full implementation independent model of the construction and the operation of the system. Moreover, an ontological model has a modular structure and its elements are (ontologically) atomic. For enterprises, the meta-model of such models is called enterprise ontology. For information systems, the meta-model is called information system ontology.
Note. At any moment in the lifetime of a system, there is only one ontological model, capturing its actual construction, though abstracted from its implementation. The ontological model of a system is comprehensive and concise, and extremely stable.
It is an ethical necessity for bestowing authorities on the people in an enterprise, and having them bear the corresponding responsibility, that these people are able to internalize the (relevant parts of the) ontological model of the enterprise and to constantly validate the correspondence of the model with the operational reality.
Note. It is the duty of enterprise engineers to provide the means to the people in an enterprise to internalize its ontological model.
To ensure that an enterprise operates in compliance with its strategic concerns, these concerns must be transformed into generic functional and constructional normative principles, which guide the (re-) development of the enterprise, in addition to the applicable specific requirements. A coherent, consistent, and hierarchically ordered set of such principles for a particular class of systems is called an architecture. The collective architectures of an enterprise are called its enterprise architecture.
Note. The term “architecture” is often used (also) for a model that is the outcome of a design process, during which some architecture is applied. We do not recommend this homonymous use of the word.
For achieving and maintaining unity and integration in the (re-) development and operation of an enterprise, organizational measures are needed, collectively called governance. The organizational competence to take and apply these measures on a continuous basis is called enterprise governance.
Enterprise Engineering Manifesto (final version – January 2011) Jan L.G. Dietz (editor)