Regulating organizations requires a ¯ne balance between central control and (local) adaptability. In this paper we report on our approach using explicit organization and coordination models based on the research performed within the European FP7 project alive. One of the principal aims of alive is to combine coordination and organization mechanisms in order to provide a °exible, high-level means to model the structure of interactions between services in the environment. Our main focus is on the implementation and integration of organizational structures and on the translation of (abstract) norms (e.g., laws and regulations) into (concrete) software systems. Such a way of abstracting from low level system complexity by the use of human- and social- oriented system requirements is very promising to cope with requirements changes, e.g., useful to develop adaptive (service-based) systems.
The deployment of regulations in human societies and in information systems show remarkable resemblances. Both ¯elds need to cope with relating the abstract level of the regulations with the concrete practice (either the \work °oor" of the human organization or the \low-level" software implementation, e.g., using service-based systems). A common tendency when relating the regulations to the practice is to directly connect the top (abstract) level with the concrete implementation, but in this paper we argue that the use of intermediate level(s) allows for a greater °exibility and, at the same time, an increased robustness of the system. This new source of (human- and social- oriented) system requirements pave the way for new challenges in software engineering. That is, recent software engineering approaches have dealt with how to endow single (agentbased) systems with the ability to cope with context changes, without taking ? This work has been performed in the framework of the FP7 project ALIVE IST215890, which is funded by the European Community. The author(s) would like to acknowledge the contributions of his (their) colleagues from ALIVE Consortium (http://www.ist-alive.eu) into account that such adaptivity properties can be easier and better studied and handled at organizational level, as often it happens in real life. A challenging aim of this paper is to bridge adaptivity at organizational level.
The research presented in this paper is part of the European FP7 project
alive, which aims to create a framework for software and service engineering,
based on combinations of coordination and organization mechanisms [
The approach taken in the alive project is to gradually translate the
regulations from the abstract level of organizational regulations into a system
description at the concrete level of service-based implementations. First, the
abstract regulations are translated into operational norms and structures, which
are more concrete than the regulations themselves. This translation is done by
adding operational information to the regulations (i.e., how a given regulation
can be achieved in a given context/domain). These operational artifacts [
One way of deploying regulations in an organization is by regimenting the participants of the organization and constrain them in such manners that they can only perform behaviour which the organization considers legal. That means, all possible actions are a priori de¯ned by the organization. While, at ¯rst glance, this appears to be a fruitful approach, it has the major disadvantage that the system loses much of its °exibility and robustness. If, however, the participants are allowed to perform actions that are not described as allowed (such actions could be illegal, but could also be not considered a priori), the participants can (e.g., through exploration) come up with more e®ective ways of doing things and react to unexpected situations which were not taking into consideration when the organizational regulations were recorded. In this case, however, the safety of the system has to be guaranteed by sanctioning participants for doing illegal actions.
Throughout this paper we will use a generic, simple example based on a simple regulation to regulate the temperature of the building at a comfortable level without wasting energy. This can be seen or described as the regulation or norm that the organization has to comply to; namely, the thermostat is obliged to keep a comfortable level of heat in the building without wasting energy. Before we translate this regulation into service speci¯cations, combining the services needed to achieve this objective, we ¯rst create an operational description of the general objective. That is to say, we give an operational meaning to the regulation, which is informing the organization, still on an abstract level but more concrete than the norm/regulation itself, how the objective is to be reached. There are alternative mappings to operational descriptions possible for this example regulation. For now, let us assume that the operational meaning of the regulation is that the temperature in the building needs to be 18 ±C whenever there are people around. Finally, this operational description of the regulation is used to combine the services (at the implementation level) in such a way that the regulation of the organization can be ful¯lled. In this case, this might mean the combination of the following services: { a service to get the day of the week; { a service to get the time of day; { services to get the temperature of every room in the building; { a service to translate temperatures in ±Fahrenheit to ±Celsius; { a service to regulate the heater/air-conditioner of the building. The services for the time of day and day of the week are needed to determine whether there are people in the building (i.e., the system does not need to use the heater/air-conditioner during evenings and weekends). The translation service from ±F to ±C is only needed if not all services (that measure the temperature or regulate the heater/air-conditioner) are speaking the same \language".
In this paper we compare the approach of alive, based on previous research
done [
New generations of networked applications based on the notion of software services that can be dynamically deployed, adjusted and composed will make it possible to create radically new types of software systems. In turn, this will require profound changes in the way in which software systems are designed, deployed and managed { exchanging existing, primarily top-down \design in isolation" engineering, to new approaches which are based on integrating new functionalities and behaviours into existing running systems already active, distributed and interdependent processes.
F o r m a l F r a m e w o r k
role
actor
SD role role actor
SD SD
SD actor
SD WS
WS WS
WS
WS
role actor SD
WS
M o d e l D r i v e n E n g i n e e r i n g
The alive project is based around the central idea that many strategies used today to organize the vastly complex interdependencies found in human social, economic behaviour will be essential to structuring future service-based software systems. More speci¯cally, the project aims to combine cutting edge Coordination and Organization mechanisms and Model Driven Design to create a framework for software and service engineering for \live" open systems of active services.
The project extends current trends in service-oriented engineering by adding three extra layers (see Figure 1).
{ The Service Layer augments and extends existing service models with semantic descriptions (SD) to make components aware of their social context and of the rules of engagement with other web services (WS). { The Coordination layer provides the means to specify, at a high level, the patterns of interaction between services, using a variety of powerful coordination techniques from recent European research in the area. { The Organization Layer provides context for the other levels { specifying the organizational rules that govern interaction and using recent developments in organizational dynamics to allow the structural adaptation of distributed systems over time.
In the following sections we focus mainly on the connections between the organizational level (where the regulations reside) and the service level by using an intermediate level. We show how the ideas of alive relate to the deployment of regulations in human organizations and allow for °exible adaptation.
system interactions practice
specification procedural information
The deployment of regulations in the alive approach consists of a gradual
transition from the organizational level to the service-based implementation (the
bottom two levels of the model in Figure 1). Given that organizations are
characterized by their rules and conventions [
First, a formal representation of the regulations is created, giving an abstract normative speci¯cation of the allowed interactions in the organization (e.g., in deontic logic). Given our example, this means a formalization like, e.g., Othermo(temperature(comf ortable)) and Fthermo(waste(energy)). Which states that thermo is obliged to make sure that the temperature is comfortable and thermo is forbidden to waste energy. The creation of a formal representation of the regulations also creates a basis for the ontology that is needed (we call this basis the normative ontology ). The normative ontology is built from: 1) the concepts and relations used in the formalization step, and 2) information taken from the ontological de¯nitions in the regulations themselves. In our example, the normative ontology contains the concepts of comf ortable, temperature, energy, etc. The normative ontology and the formal representation of the regulations can be seen as the organizational level of Figure 1.
The normative speci¯cation is also used as the basis of the implementation of the regulations. The process from normative speci¯cation to implemented norms is as follows: 1) the abstract norms are translated to concrete operational norms (although these are only useable for a certain context, i.e., this particular organization, and less expressive than abstract norms, concrete norms are a lot easier to implement); 2) the operational norms are translated into constraints and procedures that will see to it that the norm is enforced in the organization. In our example, the operational norm is the temperature in the building needs to be 18 ±C whenever there is people around. The design of interaction structures that can be used in the organization consists of the following steps: 1) the important characteristics of the norms that express how interactions should be in the organization are extracted from the norms to create a prototypical interaction structure on a high level of abstraction (we call these important steps derived from the norms landmarks, and the structure that expresses the ordering over these landmarks a landmark pattern); 2) by using procedural information and the expected capabilities of the system components an interaction structure is created to give a default manner for achieving certain objectives in the organization. For our example we can create an interaction structure by using landmarks (e.g., L1 =check temperature and L2 =adjust heater, with the temporal ordering that L1 < L2): if (today = normal weekday) then temperature := requestT emperature(servicetemp); if (temperature · 18) then turnHeaterOn. The operational norms and landmark patterns provide the intermediate level of the transition from organizational regulations to a implementation. This level can be seen as the coordination level as shown in Figure 1.
Finally, the system ontology, which contains all concepts used in the norms as well as those used in the implementation is build from the normative ontology. The normative ontology is extended with the concepts and relations that follow from the operational and procedural information that was added to create the operational norms and the interaction structures. Moreover, concepts describing the system states and actions need to be added and linked as well.
As shown in Figure 2, the following four elements are of prime importance when implementing regulations in organizations: { A common ontology, de¯ning the meaning of concepts, the roles used in the organization and the relations between di®erent contexts. { A normative speci¯cation of the allowed interactions in the organization. { Interaction structures to specify conventions in procedure mechanisms, giving a typical interaction pro¯le which should work in any circumstance. { An active enforcement mechanism to make sure that the participants of the organization adhere to the normative speci¯cation.
The ontology is needed to specify how the participants interact, de¯ning the communicative propositions that are used, and de¯ning the roles and role hierarchy that is used throughout the norms. The normative speci¯cation is the basis of the organization, specifying the legal and illegal actions in the environment. Denoted in a formal language, this speci¯cation can be used to derive the last two elements of the framework. The interaction structures de¯ne standard ways in which the legal interactions can take place in the organization. They provide a means for non-norm aware participants to perform their task in the organization, or provide a guideline for norm-aware participants to follow (to show how things can be done, though are not necessarily the only way to do it, and can be deviated from if need arises). The norm enforcement is necessary to guarantee the safety of the system. Since we do not restrict the participants of the organization to only perform the allowed actions, the organization is required to check and enforce the proper ways of acting upon the participants in the organization. Much like in the real-world, instead of equipping all cars with speed-limiting devices, one speci¯es that speeding is illegal, and checks whether everyone adheres to that norm (even if one would opt for the regimented option of installing speed-limiting devices in cars, one would still have to check that no one tampers with the device and violates the norm).
An important step of this deployment process is the addition of operational
information (taken from practice or procedures) to create an intermediate level
(in Figure 2; the operational norms and the landmarks ) that tries to capture the
essence of the organizational level, but brings it closer to the actual
implementation. Let us look at the addition of such information in more detail.
Adding Operational Information
The translation from organizational regulations from natural language to a
formal representation (the abstract normative speci¯cation) is only the ¯rst step
of the process of implementing the regulations. Usually the regulations are
expressed at a high level of abstraction, to allow the regulation to cover a wide
variety of situations and to be used for an extensive period of time without the
need for modi¯cations, it is hard to link these regulations to the concrete
situations that arise in the practice. To make the normative speci¯cation useful in the
deployment of the organization, an interpretation of the norm is needed, which
should contain concrete (organizational) meanings of the vague and abstract
terms used in the norm and which possibly contains procedural information that
can be used to simplify the enforcement of the norm. This process of interpreting
the norms to make them useable for a single context, i.e., the organization, is
referred to as contextualization [
The contextualization process is meant to give a link between the abstract terms and concepts used in the abstract normative speci¯cation and the concrete situations and concepts that exist in the practice. Where norms contain terms such as `fair' and talk about actions like `discriminating', these concepts have no clear meaning in the implementation. There are, however, states and (sequences of) action(s) in the implementation that can be classi¯ed as an interpretation of one of these vague concepts in the context of the organization. These interpretations are highly context dependent and can di®er from organization to organization. For example, in accordance with the example described in the introduction, the abstract norm regulate the heat of the building at a comfortable level without wasting energy is contextualized (e.g., based on the preferences of the people that work in the buildings) to the temperature in the building needs to be 18 ±C whenever there are people around. In another implementation, however, it could be something di®erent, e.g., the heater should be turned o® at night or when the temperature is above 68 ±F.
Although norms that result from the contextualization process are concrete
and contain only concepts that are meaningful in the organization, these norms
still require further explici¯cation before they can be implemented. Norms only
have a declarative meaning, i.e., how things should be, while abstracting from
operational meanings, which expresses how it should be achieved. Moreover,
there is more than one way to enforce a single norm and procedural information
(which is not part of the norm) will have to be used to decide how the norm is best
implemented. This second translation process of adding additional operational
and procedural information to the norms is referred to as operationalisation [
In the next section, taking advantage of recent results from adaptive system engineering approaches, we show our vision about how to cope with adaptivity requirements at the organizational level. 4
Implementing regulations for organizations that are completely static is quite straightforward. The real challenge comes when the circumstances change and the organization needs to adapt to the new situation while still trying to abide by the regulations. In this section, we focus on those features of the proposed organization framework to e®ectively deal with context changes, namely, how the organizational models for the intended (service-based) system adapts to di®erent kinds of changes. Before going into detail how our approach achieves adaptivity qualities, let us ¯rst look at how adaptivity is handled in other (recent) approaches.
A very compelling research topic within the area of software engineering
regards methods, architectures, algorithms, techniques, and tools that can be
used to support the development of adaptive systems. That is, software engineers
are looking for techniques to model important requirements for adaptive software
systems such as the ability to cope with changes of stakeholders' needs, changes
in the operational environment, and resource variability. On one hand, a quite
recent and interesting example of adaptive systems is IBM's work on autonomic
software systems [
On the other hand, promising software engineering approaches have recently
adopted goal-oriented methodologies with an extensive use of goal models (GM s),
which have been initially proposed in Distributed Arti¯cial Intelligence as a
means for capturing agent intentions and guiding agent coordination [
In [
The above approaches identify several crucial components that a
development framework should take into account to e®ectively deal with software
adaptivity. Nevertheless, how such requirements a®ect organizational structures has
not been completely addressed. Finally, in [
Adaptivity within organizations Results from the above approaches, related to specifying the system adaptivity, are useful to properly interpret and re°ect such requirements at the organizational level. Speci¯cally, we aim at illustrating by simple example scenarios that our framework (see Figure 1) can distribute the complexity {to handle context changes{ among its di®erent layers. This latter property is important to improve the °exibility and robustness of the (service-based) system. Adaptations on the lower level might violate speci¯c procedural interpretations of a regulation, but still comply to the more abstract regulation speci¯ed on a higher level. When such a situation occurs one can now change the operationalizaion of the regulation such that the new practices conform to these procedures, while preserving the same regulation at an abstract level.
Principal sources/causes of dynamic changes in the context can be described as follows.
Stakeholder needs . Changes in the stakeholder needs happen frequently in open organizations where new roles may be added and old ones are detached in order to better re°ect the market changes. In other words, stakeholder needs have to be strictly related with organizational objectives to e®ectively deal with changes of needs, e.g., re-adapting to new organization market strategies. According to our example, let us assume an enterprise 1 has to pursue the objective make employees comfortable and to do that it depends on the work and quality of thermostat devices of all departments provided by a thermostat organization. Then, let us consider that because of the market strategy, the area-manager changes her needs, delegating to each department-manager the objective minimise heating costs to pursue too, which requires reorganising its internal service providing structure. This change may result in selecting another service to play the role thermostat that is cheaper, by e.g. auctioning a new o®er. Notice that, according to Figure 1, this change is sensed at organizational level but handled at coordination level.
Environment conditions . Depending on the kind of application domain, such requirements have to re°ect real life situations into the organizational behaviour, e.g., symptoms to be forecasted (at design-time) and then anticipated (at runtime) to avoid failures in pursuing objectives. Moreover, such requirements deal also with how norms can a®ect and are related to organization objectives. According to our example, let us assume that the thermostat has a digital power meter (services to get the temperature of every room in the building ) in order to maintain its objective regulate the heat of the building to a comfortable level without wasting energy. This service periodically veri¯es whether the consumed energy in each building correctly stays into a speci¯c range. Let us also assume that, during the winter time, a couple of employees went on holiday but forgot to close their o±ce windows. This environment change (symptom) could cause the failure of the previous objective (expressed in the normative speci¯cation) if no countermeasures (enforcement mechanisms) have been considered in advance to properly handle such a fault symptom. The enforcement has to trigger another objective achievement, e.g., asking to the building attendant to check all the windows, therefore such a change mainly a®ects the coordination level of Figure 1. Moreover, to get such a process completely automated, the reasoning mechanisms have to be supported by (domain) ontologies that describe symptoms, faults, recovery objectives, and roles along their relationships. System functionalities . Although the modelling of the organizational knowledge level has a key role within the whole framework, role and objective concepts need to be properly grounded into speci¯c system functionalities (agent capabilities and/or service functionalities) in order to really a®ect and sense the environment. In other words, changes in environment and in stakeholder needs (discussed above) inherently are re°ected in the orchestration process of the service level of Figure 1, following an implicit top-down approach (see Figure 2). In the other hand, changes in system functionalities deal with a bottom-up propagation, namely, several dynamic issues can arise from the service-level and, consequently, need to be related and handled by the organizational and coordination levels. Let us consider the example sketched in Section 1, where the thermostat has to maintain the regulation the temperature in the building needs 1 According to the example of Section 1, this enterprise acts as the committer for the thermostat organization (supplier), i.e., roles commonly played within any organization. to be 18 ±C whenever there are people around (O1). To achieve this objective, the information system has to orchestrate di®erent services and then combine their results collected every time, e.g., get the day of the week (s1O1 ), get the time of day (s2O1 ), translate temperatures from ±Fahrenheit to ±Celsius (s3O1 ) because the thermostat device works in ±Fahrenheit, calculate whether the sensed temperature is in the established range (s4O1 ), and sense the environment for people presence (s5O1 ). Now, let us assume that at the time O1 had to be achieved, the system recognizes that sO1 is not available. Where and how to handle this sensed 3 change? Maybe the service level (the where) has been provided with some simple recovery function (the how ) such as searching for an equivalent service. But, the most compelling scenario arises when the service level brings about some important failure (e.g. no other equivalent service available), propagating it to the next-up level. Again using di®erent levels of abstraction in the speci¯cation now allows for di®erent solutions using di®erent types of knowledge present at those levels. 5
In this paper we presented how the alive approach can be used for the deployment of regulations and the reorganization of both human societies and information systems. The alive project aims to create a framework that combines coordination and organization mechanisms in order to provide °exible, high-level models to assist software and service engineering. A main element of the alive approach is to distribute the design of coordination and organization of servicebased implementations over di®erent levels of abstraction. At the highest level of abstraction (the organizational level) the context is de¯ned in terms of abstract regulations and objectives. These abstract norms are operationalized in the next level of abstraction (the coordination level), where operational and contextual information is added taken from procedures and practice. The lowest level of abstraction (the service level) then deploys the operational norms and structures de¯ned on the coordination level to create a service-based implementation.
The process of translating the abstract regulation to an implementation has been illustrated. In this process, the main elements are 1) an abstract normative speci¯cation, 2) a common system ontology, 3) a set of interaction structures describing default interactions, and 4) mechanisms for enforcing the norms to guarantee safety in the system. Moreover, we have shown that the translation or regulations to an implementation in practice is not a straight-forward, onestep process. The organizational regulations have to be contextualized and operationalized before they can be implemented. That is, the abstract regulations need to be translated into more concrete regulations which use only concrete concepts and relations (which are context dependent) and operational information, to express how the regulation is to be achieved/maintained, has to be added.
This paper also reports on how the proposed framework naturally ¯ts for the modelling of context (requirements) changes to better re°ect real organization behaviours. Moreover, taking advantage from system speci¯cation of selfadaptive systems, we have shown how the framework can handle such requirements at organizational and coordination levels.
As future work, we are interesting to investigate how the organizational framework should behave to deal with context changes that are not within the organization knowledge, e.g., new objectives, roles, and relationships not described in the domain ontology. This challenging research aspect is very related to both the evolutionary design and the evolutionary qualities of agent systems, namely, how to automatically update organization models from new knowledge that emerges from the service level.