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.

Posted in March 2008

Analysis of Operational Value Creation at Yahoo!


A resource-based analysis of a company’s strategy is congruent with an analysis of value creation in the company’s core: its operations. In other words, operational value creation lies at the heart of the ends and means of the enterprise; creating value for its shareholders through its competencies. Again, this confabulates with the resource-based view on strategic analysis. Furthermore, it stresses the importance of competencies in creating value through a combination of efficiency and differentiation. Analyzing the value creating performance of such processes yields important insights into the company’s strategy.


Operational Success Criteria

Yahoo!’s operational success criterion consists of strategic objectives and goals that contribute towards meeting those objectives. The most recent strategic objectives were established a few months after co-founder Jerry Yang stepped up as CEO1 and were announced during Yahoo!’s Q3 earnings conference call in 2007. The strategic objectives are:


  • To become the starting point for the most consumers on the Internet;

  • To establish Yahoo! as the “must buy” for the most advertisers;

  • To deliver industry-leading platforms that attract the most developers.


Several goals have been established to achieve these strategic objectives. Some of those goals2 are:


  • Continue to invest, innovate, and create whatever is necessary to gain more consumers.

  • Create a motivated community of developers all building uniquely compelling applications that reach hundreds of millions of Yahoo! users.

  • Accelerate overall advertising revenue growth by the end of 2008.

  • Leverage strengths and anchor properties to create the most compelling and innovative products and services.

  • Grow visits to key Yahoo! starting points and properties by approximately 15% per year over the next several years.

  • Increase the percentage of total online advertising “demand touch” to 20% of the addressable market over the next several years.

  • Change the game in Search and increase overall share of search queries.

  • Grow market share of total online advertising.

  • Generate the maximum long-term value for assets.

Performance on Operational Success Criteria 

Since Q3 of 2007 Yahoo! has been “putting substantial talent and resources behind two of the major strategic objectives.”3 The progress made up to Q4 of 2007 in these two strategic objectives is discussed below.


To become the starting point for most consumers on the Internet, Yahoo! is focusing on five properties: Home Page, Search, Mail, My Yahoo!, and Mobile. Related properties, also referred to as anchor property verticals, including Sports, Finance and News, are also being leveraged as key starting points.


An example of value creation that relies on this first strategic objective is Yahoo!’s Home Page. It remains the most visited web page on the Internet, in part as a result of “deliberate efforts to program relevant information from across the web, regardless of whether the landing page is a Yahoo!-owned site or a third party site.”4


Value creation is also present in some of the company’s key initiatives, among them Search, Mail and Mobile. In Search, the company is encouraging innovation, most recently by investing in an open source development of grid computing that improves the throughput and scalability of Yahoo!’s services. In Mail, Yahoo!’s recent acquisition of Zimbra is expected to drive innovative developments. And finally in Mobile, Yahoo! introduced the Yahoo! Go a platform for “personalized communications, entertainment and information services to mobile devices, televisions and desktops.”5


To establish Yahoo! as the “must” buy for the most advertisers, the company’s second strategic objective, it has sustained increased financial gains on Panama6 – the company’s new marketing ranking system for online advertisements – representing a 20% improvement over previous quarters. More so, Yahoo! has continued to build a partner network for ad display with companies like eBay and AT&T. In addition, the grid computing initiative is also expected to create value in search and marketing.


Performance Analysis

The strategic objectives driving Yahoo!’s developments in value creation are part of a coherent strategy that is ultimately aimed towards achieving differentiation. By becoming the starting point for users and by satisfying their needs, Yahoo! is attempting to create lock-in through quality that users will start-off with and come back to, which would essentially mean conquering one of the greatest challenges in the Internet industry, namely the lack of lock-in effects. Yahoo! realizes that “revenue from your locked-in customers is the return on the investment you have made in them.”7 To this end, the company is investing in differentiation.

Even though the home page of Yahoo! is the most visited site on the Internet, the company’s search capabilities, which are the defining competency required for online advertising, are still lagging behind Google’s. The Panama project was launched for this reason and will be a defining factor in Yahoo!’s evolution in value creation.


Acquisitions and partnerships are beneficial competencies for value creation in the rapidly changing Internet environment. Yahoo! has effectively leveraged and integrated these resources into its operating routines for value creation.


Financial Performance Analysis

The table below shows Yahoo!’s key financial figures for the years between 2002 and 2007. The analysis below will be used in comparison to the Operational Cash-flow Development analysis in the next section.


Table 1

Yahoo! Inc (NASDAQ: YHOO)










Net Profit







Gross Margin

Total Operating Expense
































































































Yahoo!’s net profits rose to a high of $1.9 billion in 2005 after which they declined to a four year low of $660 million. The company’s 8% ROI, the highest to date, coupled with their all time high ROE of 22% in 2005, and the associated decline in subsequent years, are witness to the fact of the fierce competition inherent in this industry sector. Nevertheless, it is also related to Yahoo!’s strategic changes during those years. Both competition and strategic changes have been crucial developments in the company’s evolution.


The 18% ROA in 2005, shows that Yahoo! consistently increased efficiency after the Dot-com crash in 2000. The years after that show declining efficiency, again related to competition and strategic changes. Furthermore, the gross margin shows, to some extent, the difference between fixed and variable costs and in turn gives us an insight into the company’s break-even.


In relation to the break-even point, gross margin has remained stable at around 60% for the past 4 years while operating expenses continue to rise, clearly indicating an increasing drop in efficiency.


Operational Cash-flow Development Analysis 

The table below shows the key financial figures for Yahoo! for a more extensive period, covering the years between 1998 and 2007. Based on these numbers Figures 1 and 2 show the Performance-volume and Differentiation-efficiency relations.


Table 2

Yahoo! Inc (NASDAQ: YHOO)







Employment costs


Non operational results


Net profit
















































































































Yahoo!’s Performance-volume relation shown in Figure 1 below, shows the confusion that came about with the Dot-com crash in 2000. After a period of increasing performance and volume, up to 2005, Yahoo!’s situation dramatically changed with a significant drop in performance with increasing volume. This coincides with the drop in efficiency identified in the financial break-even analysis and is supported by Figure 2. Furthermore, it explains the change in leadership and strategy in late 2006 – point at which the situation started improving.



Figure 1




The figure below shows at one extreme a drop in efficiency and increased differentiation that came about with the Dot-com crash, of which Yahoo! was a survivor. At the other end it shows a drop in efficiency, after a period of steadily decreasing differentiation, that is the result of increasing competition and strategic changes within the company. These conditions caused a dramatic turn in efficiency after a high in differentiation-efficiency in 2005. This sudden drop in efficiency, which has continued since 2005, confirms the break-even analysis and the analysis from Figure 1.


Figure 2


Strategic Stability Analysis

Yahoo! has changed its strategy several times over the past few years. Most recently, in October of 2007 it announced yet another shift in strategy. Although such a change was in order, especially with the new vision of co-founder and new CEO Jerry Yang, such changes have a deep and far reaching impact in the company’s value creation capabilities. In this case, the changes have been mostly positive but still require further development.


The guidelines provided by three core strategic objectives, and its supporting goals, are effective in setting a clear direction for the company. However, these same objectives must be maintained in coming years in order to be most effective.



Yahoo!’s financial performance has significantly decreased since 2005. The company has not been successful according to its own performance criteria, as is evidenced by its increasing break-even point and fairly stable gross margins. Furthermore, the company has not been successful according to standard performance criteria such as ROI, ROE, ROA, EBIT(D)(A), all of which have decreased from highs in 2005.


The company’s strategic orientation, after new CEO Jerry Yang was appointed and the company revamped its strategy, is to increase differentiation. This is strongly supported by all three of the company’s strategic objectives and most of the current company goals, both geared specifically towards differentiation. It is clear that the company’s generic strategy is predominantly focused on differentiation.


The company’s strategic direction was not successful after 2005. This is evidenced by the changes in top management and strategy, and supported by this financial value creation analysis. Furthermore, the company’s strategic direction has been fairly unstable in the past 5 years indicating the importance of adaptability and agility in this highly unstable environment.






1 Yahoo! Co-Founder Jerry Yang Named Chief Executive Officer,” Yahoo! press release, June 18, 2007, http://yhoo.client.shareholder.com/press/ReleaseDetail.cfm?ReleaseID=249882accessed March 1, 2008.

2 Adapted from Yahoo! Q3 2007 and Q4 2007 earnings calls.


 Demand touch includes ad revenues and associated expenditures.


3 Yahoo! Q4 2007 Earnings Cast,” Yahoo! investor relations, January 29, 2008, http://advision.webevents.yahoo.com/yahoo/earnings/2007/Q4/accessed February 28, 2008.

4 Yahoo! Q4 2007 Earnings Cast,” Yahoo! investor relations, January 29, 2008, http://advision.webevents.yahoo.com/yahoo/earnings/2007/Q4/accessed February 28, 2008.

5 Yahoo! Expands Reach Beyond the Browser with Launch of Yahoo! Go; Yahoo! Go Brings Seamless and Personalized Communications, Entertainment and Information Services to Mobile Devices, Televisions and Desktops,” Yahoo! press release, January 6, 2006,http://yhoo.client.shareholder.com/press/ReleaseDetail.cfm?ReleaseID=183436, accessed March 2, 2008.

6 Yahoo! To Launch New Search Marketing Ranking Model in the U.S. On February 5,” Yahoo! press release, January 23, 2007, http://advision.webevents.yahoo.com/yahoo/earnings/2007/Q4/accessed March 1, 2008.

7 Shapiro C., Varian H. R., (1999) Information Rules: A Strategic Guide to the Network Economy, Cambridge, MA: Harvard Business School Press.

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. 


The “Indivers Phenomenon”

Today I attended the "Indivers Phenomenon" lecture by Dr. Bert Twaalfhoven, the newest in the series organized by ABC Delft. The lecture was lively and had an up-close-and-cozy feel to it, in part because of the great venue and crisp quality sound from the hazzle-free wireless speaker system (something key for lectures in my opinion) It was held at the Theater de Veste and featured great guests and some nice snacks and refreshments. 

I thoroughly enjoyed Dr. Twaalfhoven's lecture, he is an oustanding speaker or "preacher" as he himself puts it. In his lecture, I noted three key take-aways that I believe are very insightful and useful to keep in mind.

  • Study the cascade of suppliers. Understand your industry, know what's going on, and perform thorough analysis.
  • Understand the barriers of entry to your industry, perform thorough analysis including cases of failure.
  • Always make a negative business plan. Dare to make it negative, and follow-up on it on a month-by-month basis.

I'm already looking forward to ABC Delft's next lecture…

The evolution of an Internet leader

I recently found out that the deadlines are not (hard) deadlines but instead meant to help us turn in the assignments on time. This helped me make a better analysis this time (and turn it in at a decent hour) for which I received very positive comments! I hope you like it, comments are welcome.

This module was about analyzing company evolution. For this we had to identify the evolutionary stage and business functions of the firm, and analyze the coherence of both. 

The evolution of an Internet leader

The value drivers of a firm have a significant influence on the core competencies the firm develops over time. These capabilities, in turn, influence the products and services that the firm offers in the market, characterize a firm's value chain and can have a significant effect on its value system. For the majority of firms, core competencies and underlying value drivers have an effect on the firm's evolution. Analyzing this evolution is useful for evaluating the effectiveness of strategy.

Continue reading

© 2011 TU Delft