De meningen ge-uit door medewerkers en studenten van de TU Delft en de commentaren die zijn gegeven reflecteren niet perse de mening(en) van de TU Delft. De TU Delft is dan ook niet verantwoordelijk voor de inhoud van hetgeen op de TU Delft weblogs zichtbaar is. Wel vindt de TU Delft het belangrijk - en ook waarde toevoegend - dat medewerkers en studenten op deze, door de TU Delft gefaciliteerde, omgeving hun mening kunnen geven.

Architecture and Enterprise Engineering


Architecture and Enterprise Engineering


Architecture is a verb, not a noun. Though grammatically incorrect, this symbolic statement is true to the extent that architecture prescribes the state space and transition space of a system. Such is the case of Enterprise Engineering, which sees enterprises as systems and defines architecture as the “normative restriction of design freedom.”[1] The fact that architecture can be thought of as a verb in this field implies that it is part of a set of actions that influence the world surrounding its use. In this sense applying a prescriptive notion of architecture. This is evident from the intimate relation of architecture to the design and engineering of systems, where normative restrictions are the most actionable and are present at different conceptual and operational levels. 

Modeling an enterprise as a system is useful to acquire knowledge of its function and to develop an understanding of its construction. Correspondingly, different conceptual models of systems are employed to better grasp this dichotomy; these are the functional and constructional models of systems. Through these models the enterprise engineer can acquire and develop a conceptualization of the system that is an “understanding of its construction and operation in a fully implementation independent way.”[1] This is done in the context of a ‘generic system development process’ in which design and engineering are central activities.

This implementation independent conceptualization of a system facilitates a high level view of its core elements and their inter-relationships. This yields an understanding of the system that is in line with the notion of system ontology as applied in [2]. The underlying (enterprise) ontology will then contain the essence of the enterprise and together with the applicable (enterprise) architecture[2] can be used for (re) designing and (re) engineering a system, such as an enterprise. These notions of Enterprise Ontology and Enterprise Architecture have evolved into complementary notions in the field of Enterprise Engineering; together they effectively consider an enterprise as “a designed, engineered and implemented system.”[1] 

Such an ontology-based system can provide, among others, services over the World Wide Web, a context in which the notion of ontology has largely been relied upon, most notably in the Semantic Web. The recent Pragmatic Web Manifesto[3] signals a fertile ground for the application of Enterprise Engineering, both by relying on ontology as a “formal, explicit specification of a shared conceptualization”[1], and the prescriptive notion of architecture as a source of agreed upon design principles.  One such application could be to provide the principles for the (re) design and (re) engineering of (virtual) enterprises on the Pragmatic Web. It is an exciting time to study the field Enterprise Engineering. 

This report will concentrate on exploring the role of architecture in Information Systems Development (ISD) by concentrating specifically on the design and engineering of business processes and ICT-applications. I will argue that the notion of architecture and the act of architecturing are essential in the (re) design and (re) engineering of business processes and ICT-applications, and are key enablers, to the same effect, of organizations and enterprises. This report constitutes the first assignment for the course Enterprise Architecture & Web Services imparted by Prof. Jan Dietz. The content is largely based on the publications and lectures of Prof. Jan Dietz, Dr. Antonia Albani and Dr. Jan Hoogervorst.

This report is organized as follows: The section on architecture discusses the definition of architecture and other, often conflicting, definitions. Then there is a discussion of architecture framework, leading to a more formal definition of architecture, and specifically discussing the eXtensible Architecture Framework. Following this there is a discussion of the notions of model and system needed for the subsequent discussion of the application of architecture to the business processes and ICT-applications of an enterprise. Some conclusions are drawn from the report and given in the last section.

2. Architecture


Conceptually, architecture is the “normative restriction of design freedom”[1] and operationally it is “a consistent and coherent set of design principles.”[1] These theoretical and practical definitions are best understood in a system development process. In such a process the creators of systems rely on abstractions and the knowledge they have about the world to create (intermediate) representations of systems. A useful artifact to this end is the notion of “model.”

There are several models used in Enterprise Engineering, among the most useful in the development of systems are the black-box and white-box models, regarding the function and construction of systems, and the ontological and implementation models, respectively at the highest and lowest level of abstraction of in the construction of a system. These models are useful for obtaining information about the system to be realized, even if only intermediately, and ultimately for gaining knowledge about the function and construction of the system, and at the highest level of abstraction, about its essence. All these models are used in the development of systems.

In the ‘generic system development process’ two types of systems are involved, namely a using system and an object system. The former making use of the functionality provided by the latter, which is the object of attention. There are well-delineated activities involved in this development process that are concerned with the design, engineering, and implementation of an object system. The first of these activities, namely designing, consists of two phases, determining requirements and devising specifications. Both phases are needed to bring about an object system, both in regards to its inputs and outputs as well as to its construction. These activities involve possessing knowledge about the using system and the object system, insofar as the function and construction of these systems is concerned. Hence, the black-box and white-box models are useful in the process of designing systems. These models are shown in the figure below in relation to the design of an Object System (OS) on the basis of a Using System (US). 

Figure 1 [8]

Models of differing levels of abstraction are useful in the engineering and implementation of systems, the other two activities involved in the ‘generic system development process.’ At the highest level of abstraction, therefore in a “fully implementation independent way”, an ontological model shows the essence of a system. The word ontology, from which the idea for this model comes from, refers to the nature of being and “requires us to make a strict distinction between the observing subject and the observed object.”[2] The importance of this distinction will be discussed in latter sections.

There is an ontological model, therefore the highest constructional model, for each type of system, as well as an implementation model. Several layers of abstraction separate both models. At the lowest constructional model, which is the implementation model, the assignment of technological means to the elements of the model is referred to as implementation. The construction of the implementation model from the ontological model, an activity that usually iterates between several intermediate models, is referred to as engineering. These activities are performed completely within the object system in the ‘generic system development process’ shown in Figure 2 below.

 Figure 2[8]

With this conceptual framework in place, it is now possible to define, and better understand, architecture as the “normative restriction of design freedom.”[1] The operational notion of architecture as “a consistent and coherent set of design principles that embody general requirements.”[1] also becomes clearer. It is now possible to give a more formal definition of architecture, in relation to which a fourth activity in the system development process can be described; these topics will be covered in the next section. More will be said about requirements and principles in the section on ‘Design and Engineering.’ 

Figure 3 [8]

Other Definitions

There are other definitions of architecture that go around; often they are conflicting or ill defined. Some examples include those of Zachman, IEEE P1471 and TOGAF; we will examine each of these in turn. The first, states that:


  • “Architecture is that set of design artifacts, ordescriptive representations, that are relevant for describing an object, suchthat it can be produced to requirements as well as maintained over the periodof its useful life.”[4]


This definition is descriptive, as such it says nothing about the construction of systems. Notions about the construction of a system are necessary for constructional system design.

Another definition is that of IEEE P1471, related to the one given in TOGAF, it states:

  • “Architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.”[5]


This definition is also descriptive and has the added problem that it contains two definitions within it. The same issues are found with the definition of architecture found in TOGAF, which states that architecture is:


  • “A formal description of a system, or a detailed plan of the system at component level to guide its implementation. The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time.”[6]


These definitions have in common that they describe architecture, in doing so they comprise what is known as the descriptive notion of architecture. For the design and engineering of systems, the prescriptive notion is also needed. Such notion is given by the conceptual and operational definitions of architecture that are part of the field of Enterprise Engineering. These definitions will provide a set of design principles that are useful in a particular architecture framework; this is the subject of the next section. 


3. Architecture Framework


An architecture framework is “a conceptual structure pertinent to a certain system type, consisting of areas of concern and a necessary and sufficient set of design domains pertinent to a chosen perception.”[7] Informally, it is “a structured checklist of issues that must be paid attention to or that must be taken into account.”[8] It gives rise to the activity of architecturing, or architecting, which is the “heuristic, participative process that defines the principles of architecture.”[7] 

Such a conceptual structure is formally defined[9] as a tuple <S,D,A> where:

  • S is a set of system types.
  • D is a set of design domains.
  • A is a set of areas of concern.

These dimensions are assumed to be orthogonal.

This purposefully broad and generic definition allows an Architecture Framework to cover systems, the design of those systems, and areas of concern for the design of those systems, and to do so in relation to their function and construction. Furthermore, it allows for the definition of an “AF as an extension of one or more existing AF’s, while also being extensible itself.”[8] 

The eXtensible Architecture Framework (xAF) is based on the definition of Architecture Framework given above. It consists of a Generic Architecture Framework (GAF) and rules for extending it. The generic architecture framework serves as a universal root xAF, referred to as xAF0, for other xAF nodes. It can be extended through rules for specialization and integration, respectively used to specify an Architecture Framework in more detail or to unite several Architecture Frameworks into a more elaborate structure.

The specialization rule is defined in terms of two Architecture Frameworks xAFi and xAFj. An xAFj is defined as <Sj,Dj,Aj> is a specialization of an xAFi defined as <Si,Di,Ai> if and only if:

Every system type s Sj is an exclusive subtype of some s Si 

  • Dj   Di.
  • A Ai.
  • xAFi is a valid xAF.

The integration rule is defined in terms of several xAF’s as follows:

An xAFn, defined[9] as <S, D, A> is an integration set of xAF’s defined[9] as {<S1,D1,A1>, <S2,D2,A2>, … , <Sk,Dk,Ak>}, if and only if:

  • S is the integral union of S1,S2, … , Sk.
  • D is the integral union of D1,D2, … , Dk.
  • A is the integral union of A1,A2, … , Ak.
  • xAFn is a valid xAF. 

An example specialization for xAF systems in general is that of an xAF node for organizations. In related fashion, an example of integration – involving the resulting xAF node – is the integration of an organization xAF node, an information system xAF node and an ICT-infrastructure xAF node.

The resulting structure, through use of the specialization and integration rules, is an xAF lattice. As shown in the figure below it is a top-down structure of xAF nodes, where a straight line represents specialization and an xAF node reached through dotted lines represents integration. 

Figure 4 [8]

The specialization and subsequent (possible) integration of xAF nodes becomes interesting to the extent that it specifies heterogeneous systems. This follows from the fact that the xAF0 node represents a homogeneous system, and the xAFi’s are, to differing extents, heterogeneous systems. It is necessary, then, to define homogeneous system.

The root xAF, referred to as xAF0, is a generic homogeneous system that can be defined[9] in relation to the formal definition of a homogeneous system as a tuple <A,C,E,P,S> where:

  • A is the class of atomic elements of the system category.
  • C A, called the composition.
  • E A, called the environment. E and C are disjoint

P is a set of products. Products are things that are brought about by the elements in C for the benefit of the elements in E.

S, called the structure, is a set of influencing bonds among the elements in C and E. By virtue of these bonds, the elements are able to act upon each other. Within patterns of such interaction the products in P are brought about.

As heterogeneous systems can be characterized by xAF nodes, it is interesting to gain knowledge about the architecture of those nodes – as it will be determinant to the design and (subsequent) engineering of systems. It is necessary, then, to define architecture more formally.

An architecture within a particular architecture framework can be defined more formally as a set P of design principles, such that every p  P:

  • concerns one system type s  S,
  • is a restriction of design freedom in one domain d  D, and
  • accommodates one or more areas of concern a  A. 

To evaluate the influence of architecture on the design and engineering of business processes and ICT-applications it is necessary to review the notions of model and system. This is the subject of the next section and will be covered in relation to the DEMO methodology and the concepts of Enterprise Ontology.


4. The Notions of Model and System

The notion of architecture is an essential part of the emerging field of Enterprise Engineering. This field has its roots in the DEMO methodology, which is part of the Language/Action Perspective (LAP). This theory is used as a basis for the design of Information Systems — “the Language/Action Perspective is an approach that is based upon analysis of communication as a basis for the design of Information Systems.”[10] Communication plays a central role in both DEMO and LAP, as a means to achieve mutual understanding in the latter, based on Speech Acts Theory and the Theory of Communicative Action, and in the former as the basis of three modes – essential, informational and documental – of communication in organizations. Furthermore, communication is at the root of the study of Enterprise Ontology, one of the pillars of Enterprise Engineering. 

The Design and Engineering Methodology for Organizations – DEMO – as well as Enterprise Engineering focus on the study of systems, specifically organizations and enterprises as systems. Both draw their foundational system notion from the ontology of Bunge, which in the case of Enterprise Ontology is explicitly referred to as ontological system, and organization  in the case of DEMO. The definition of organization (as a system) in DEMO is closely related to that of ontological system, although the definition of the latter in Enterprise Ontology is broader and more formal[2]. In any case, both methodology and theory pursue the same premise: the enterprise (or organization) as a system. The notion of ontological system[2] is defined below.

Something is a system if and only if it has the following properties: 

  • Composition: a set of elements of some category (physical, social, biological, etc.). 
  • Environment: a set of elements of the same category; the composition and the environment are disjoint. 
  • Production: the elements in the composition produce things (e.g., goods or services) that are delivered to the elements in the environment. 
  • Structure: a set of influence bonds among the elements in the composition, and between them and the elements in the environment. 

Once “something” has met the criteria above, it will either be suitable for design, and (possible) subsequent engineering and implementation, in Enterprise Engineering. In this field, the conceptual model of an enterprise, or ontological model as it is referred to, will be central to the design and engineering of a system. In fact, the notion of model is considered to be of comparable importance to that of system. A model is defined as — “Any subject using a system A that is neither directly nor indirectly interacting with a system B, to obtain information about the system B, is using A as a model for B.”[2] 

The ontological model of a system, such as an enterprise, serves as the conceptual model used to obtain the essence of the system in a coherent, comprehensive, consistent, and concise way, yielding as a result information about the ontology of the system.  This ontology is used in the process of design and engineering of systems. This will be done in regards to the function or construction of the system, depending on the phases or iterations of system design and engineering. To this end, two types of models are employed, namely the white-box and black-box models that were mentioned previously. 

In the case of the white-box model “it is a direct conceptualization of the ontological system definition”[2] and relates to the construction (and operation) of the system. The black-box model, on the other hand, relates to the function (and behavior) of the system.  The process of design, as mentioned previously, consists of two phases. These are split on the basis of reliance on the constructional or functional, hence white-box or black-box, model of the system, and correspondingly are called the analysis and synthesis phases of design. Similarly, the process of engineering of a system relies on the constructional, or white-box, model of the system. 

There are three key observations in the design and engineering of systems. The first is that the ontological model of the system is the best source of constructional information about the system, and hence should be used as the basis for the design and engineering of systems. The second observation is that functional and constructional design are always alternated with each other, this is best explained as follows — “a function cannot support another function directly, because functions do not have needs; only constructions do.”[2] And finally, the third observation is there is a philosophical stance behind the use of ontology in the design and engineering of systems that “requires us to make a strict distinction between the observing subject and the observed object.”[2]

Architecture and architecturing are of paramount importance in the development of systems. The activity of architecting results in the principles of architecture, which are used for (re) designing and (re) engineering systems. These principles are the result of using a framework “to support the devising of architectures.”[9] With this (richer) conceptual framework in place it is now possible to delve deeper into the details of design and engineering of business processes and ICT-applications. 


5. Design and Engineering

The design and engineering of business processes and ICT-applications are central concerns in the field of Enterprise Engineering. The major pillars of this field, namely Enterprise Ontology and Enterprise Architecture, are instrumental in this development process and provide much of the constructional knowledge necessary to effectively design organizations. At the core of the field, within the notions of Architecture and Ontology, lies much of its conceptual and practical power; one example is enabling the creation of Information Systems that deal with both social and technical aspects.

The two main areas of focus in the design and engineering of systems are business processes and ICT-applications. Business processes are mainly part of the realization of an organization and ICT-applications of its implementation. For the realization of an organization a layered integration of three aspect organizations is performed. The implementation of the organization is “the making operational of the organization’s realization by means of technology.”[2] It is imperative, then, to understand the different application and organization layers that are involved in an organization, namely B-I-and-D applications and organizations. Following the formal definition of architecture, within the architecture framework of an organization, and relying on the conceptual and operational notions of architecture, the design and engineering of business processes and ICT-applications will be bounded by the principles of architecture. To understand this, it is necessary to explore the systems, design domains, and areas of concern that are used to establish design principles.



System Types

For the system types the organization theorem[2] of Enterprise Ontology is used. According to the organization theorem, an organization consists of three layers: the B-organization (from Business), the I-organization (from Intellect), and the D-organization (from Document). The D-organization supports the I-organization and the I-organization supports the B-organization. These organizational layers are supported by ICT systems, which can be divided into four categories: B-applications, I-applications and D-applications and hardware. D-applications support I-applications, and I-applications support B-applications. Hardware is defined as a separate system type, on which the applications run.

The difference between the B-, I- and D-organization and B-, I- and D-applications lies in the nature of the activities that are executed at each level and the technologies they rely upon to improve the efficiency of the processes these applications deal with. The D-organization and D-applications are concerned with datalogical activities. Datalogical activities are activities where only the form of information is concerned. Examples include copying, storing etc. The I-organization and I-applications are concerned with the infological activities. Infological activities are activities that are concerned with the content of information. Examples are inquiring and calculating.  The B-organization is the part of an organization that performs ontological activities. Ontological activities are those activities where something is actually brought about. Examples are deciding and judging. Business processes are predominantly ingrained in the B-organization and are implemented through a mix of B-applications and actor technologies. 

The figure below shows a graphical representation of the organization theorem, it shows the three organizations and the kind of production acts their actors perform. The divisions of the figure relate to the coordination, actor roles and production.

Figure 5  [2]

Design Domains

As we have seen above, the different layers support each other: lower-level layers support higher-level layers. We have also seen that two design domains can be distinguished: a functional and a constructional design domain. This division also accounts for the organization theorem:  the functional layer of the D-organization supports the constructional layer of the I-organization; the functional layer of the I-organization supports the constructional layer of the B-organization.

The figure below depicts the system types and design domains of Enterprise Ontology. The design domains are represented by the F (for functional layer) and C (for constructional layer)[9]. 

Figure 6 [2]

Areas of Concern

Areas of concern are classifications of principles, defined by stakeholders of the Using System. They can partially overlap each other. Also, priority can be given, but is mostly not formalized. This leaves room for extension and specialization across the different types of organizations identified previously. 


6. Application to Enterprises

One application of architecture to enterprises is in (improving) the design and engineering of Web services. By providing business functionality, that comes from business processes, in the form of services, enterprises can extend their deployments of ICT-applications within the enterprise or to other enterprises. These extensions, however, require some alignment. 


Concepts like SOA aim at “aligning business and information technology (IT) in order to increase flexibility and to have the possibility of quickly adapt to fast changing market requirements.” However, the extensive and complex standards commonly used in SOA, such as SOAP, can inhibit the effectiveness of architectural principles and add overhead to network communications. An alternative is provided by the Representional State Transfer (REST)[12] architectural style.


A known problem with existing Web services implementations is the lack of agreement in the semantics of SOAP and WSDL. At the core of this agreement is the ontology of what is being agreed upon. To this effect, the notions of Enterprise Ontology and Enterprise Architecture are central to the alignment of (virtual) enterprises on the Pragmatic Web[3]. By agreeing on an ontology, communities of interest and practice, such as enterprises, could rely on the powerful notions of architecture in the design and engineering of (new) web services. Such efforts would be more efficient and effective through the use of architectural styles like REST. 


7. Conclusions

The prescriptive notion of architecture is a theoretically sound and practically useful notion. This is evidenced by the conceptual and operational definitions of architecture and their influence on the design and engineering of systems.

The architecturing of an organization is a transitive verb, whose object is the design principles of an organization. The term architecture also denotes action as is evident from its normative definition. Together, they are a fundamental part of the systems development process. The prescriptive notion of architecture is instrumental in this process.

The notions of ontological system and ontological model are useful, in fact essential, for the definition of architecture and architecture framework. 


Be Sociable, Share!

Leave a Reply

© 2011 TU Delft