Disclaimer

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.

Posts in category Enterprise Architecture & Web Services

A code summer of cold

GSoC 

This summer I participated in Google Summer of Code, mostly out of my office for the summer: the cold library of TU Delft. During the weekdays I worked on my project (Incubating an Android in Delft) in the library, and because it was empty, well, it was a bit colder than usual. Obvious you will say, but I truly didn’t expect having to wear a heavy sweater during the summer, and much less to be in the library! But it turned out to be an outstandingly interesting experience from which I learned about a new technology (SCA), learned to do things in the open-source way, and was able to explore possible topics for my thesis, in addition to studying for a decision-making re-exam!

My GSoC project was about getting Apache Tuscany to run on Android, Google’s new mobile phone platform. Because of the lack of annotations support in the previous SDK (which I was using back then) I couldn’t actually get it to run. However, I was able to produce a reduced set of modules for a lightweight Tuscany runtime – one of the main goals of my project proposal. Recently, Google released an updated version of the SDK. I’m continuing the work I started in GSoC to finally see Tuscany running on Android! 

Something nice about GSoC was the freedom to work when and where I wanted to. Often this meant working at night and enjoying the day, or the other way around, or on weekends, or weekdays, or just a bit here and there, or well, what have you. In the end, I found that it was actually a lot of work, but also interesting work, of a kind I hadn’t actually done before.  Initially it was a big challenge to even manage to get out of bed and start working. Then I found out that setting small goals helped to get some inertia, and eventually helped me get into a flexible regime in which I was, in the end, working several hours per day without actually feeling that I was working. At times, the project became more like a hobby and less like a job.

I started off by proposing a project, setting deadlines, milestones, deliverables; what you would expect if you’ve ever taken a project management course or, well, managed a project. Well into the project I found that I wasn’t going to be able to meet some of the deadlines I had proposed. Something, perhaps, usual in software development projects. But also important in open-source collaboration, I found, is the process. Many times, it is actually more about ‘process’, and less about ‘project’. More specifically, because open-source projects involve mostly volunteers, deadlines are not that important. There is no hierarchy in open-source projects, in the sense that there is no command-and-control, no single individual or group has the power to make people do things in a certain order or specific way, following for instance a rigid set of rules. Instead, doing the right things is what matters. It was actually kind of cool that I was reading about this stuff, because I was studying for a decision-making re-exam, and being able to draw a parallel to the actual work I was doing with GSoC. So, to make it short, I followed the process orientation (like that of decision-making in networks), and presented my findings and progress using a project management approach, while actually working behind the scenes, in a way that more resembled that of process management. In short, I found management in open-source projects to be a fascinating topic which will likely be the research topic of my thesis.

Another nice thing about GSoC is that it allowed me to do work related to my academic pursuits, exactly as defined in the goals of the program. Throughout the project I worked on a research paper for the course IN4071: Internet Technology. Together with a colleague from the Norwegian University of Science and Technology (NTNU), who was in Delft as an exchange student, we explored the Service Component Architecture and Apache Tuscany. Recently we learned that we received a 9 for the course! Those interested in taking a look can find our research paper here: Exploring SCA and Apache Tuscany.

Back to the project, err, process. The GSoC program has two go/no-go moments in which students and mentors fill in a mid-term and a final evaluation. These are surveys with detailed questions about the progress that has been made in the project, and also provide an opportunity to make recommendations and express specific views with regards to the program. Among the questions there was one that got me thinking about the benefits of combining academic pursuits with practical work experience, specifically when collaborating on an open-source project.

Below is an excerpt of the answer I gave to the question:

  •  What advice would you give to future would-be Summer of Code students who would like to work with your organization?

I would advice them to consider the program as a starting point for their Master (or Bachelor) thesis. Combining a graduate (or undergraduate) education with the practical experience acquired in an open-source project is a great mix. For example, MIT offered an experimental course [1] this spring on ‘Building mobile applications with Android.’ Students worked on a project idea and focused on bringing it to the prototype phase with the help of mentors, professional software developers from the Boston area. This closely resembles the GSoC setup for Apache Tuscany, and for many other GSoC projects, in which projects involve building software applications and students have 2 mentors with whom they can consult throughout their project. I would recommend students to get involved with Apache Tuscany, or any other mentoring organization for that matter, well before their project starts. Students with less experience in open-source could consider assembling a project team. At TU Delft, for example, there is a Design Challenge [2] inspired on Standford’s "d.school" in which students work together on projects from companies over a period of 4 months. The same setup could be used for groups of students starting early on their GSoC project with Apache Tuscany.

Earlier today I sent my final email for GSoC’08. In all, it was an incredible experience, well worth repeating, and also recommendable for any students looking for a cool (even cold) summer internship. I liked the program so much that I’m considering being a mentor next year. So if you’re interested in applying to the next GSoC and have any questions, please don’t hesitate to contact me: o.v.castanedavillagran@student.tudelft.nl

 

References 

[1] http://people.csail.mit.edu/hal/mobile-apps-spring-08/

[2] http://designchallenge.tudelft.nl

Incubating an Android in Delft

After some weeks of anxiously waiting, the results from Google's Summer of Code are finally out. And…my proposal was chosen!

I applied for a project from Apache Tuscany, an incubator project of the Apache Software Foundation. Apache Tuscany is developing an open-source implementation of the Service Component Architecture (SCA) specification. One of the aims is to create a 'simple' service-based model for the construction, assembly and deployment of services. This enables developers to create service components and to assemble components into applications called composites.

More specifically, my project is about allowing Google Android applications to easily consume business services. In creating Android, Google and the Open Handset Alliance, were looking to provide developers with a platform and the set of tools needed to develop new types of experiences. The Android software stack includes the building blocks needed to achieve this, and is sufficiently open and extensible to allow those pieces to be combined in new and innovative ways. In my opinion, the Apache Tuscany project can empower users, another all-important source of innovation, by providing them with a "Service Development Kit" that allows them to easily and intuitively combine services in such a way as to create new types of experiences.

The Apache Tuscany incubator project implements the SCA specification and enables users and developers to create service components and to assemble components into applications called composites. Such applications in Android can be assembled out of Google services available as SCA components, provided that Android has a thin SCA core/runtime to perform such assemblies allowing applications to easily consume business services. Developing this SCA core/runtime for Android is the focus of my project for GSoc.

I envision a future of open source services created by groups of individuals pursuing a common set of goals and possibly with the same set of beliefs. Such services would be created in an environment of open communication and collaboration, much like the way software has been created for years in open source projects and to a similar extent how services have been created by Google. Furthermore, the principles and philosophy of open source would drive efforts to produce these so-called open services, with the cooperation of individuals, corporations, universities and governments. Countless applications can arise out of such efforts from which society at large would benefit. This is a very exciting time to contribute to projects like Apache Tuscany!! I will proudly wear the GSoc t-shirt after this summer!

I would like to thank the Apache Tuscany community, especially the project mentors for GSoc. Their help was vital in creating my proposal. I'm looking forward to this great opportunity!

My accepted application proposal can be found here:

Allow Google Android applications to easily consume business services

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

Definition

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

Definition

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. 

 References

The Influence of Architecture on Design

Hoi!

I'm a first year master student of TBM studying
Management of Technology. In this first blog post I include my
contribution to a paper for the first Integration Moment of MoT.
It's about eBay's acquisition of Skype and how the design of synergies
can become an integral part of the acquisition criteria.

These
first sections of the paper were meant to introduce the design problem
and explore the influence of architecture on design. Because of the
vagueness of it all, the approach of approximations is particularly
useful. After this, the paper explores a little of eBay's immense
architecture, too big and complex, in my opinion, to grasp and pretend
to cover without the insider knowledge of an eBay expert. For this
reason we decided to include Dan Pritchett's point of view of eBay's architecture. I hope you enjoy reading it, I certainly had a lot of fun writing creatively about the influence of architecture on design.

Your comments of this piece are welcomed and appreciated.

N.B. Some images are missing, but they are available on Dan Pritchet's slides about "The eBay Architecture."

Continue reading

© 2011 TU Delft